Change Details

As part of migrating m3api off of GitHub, all the current CI needs to be ported to GitLab.

As part of migrating m3api off of GitHub, all the current CI needs to be ported to GitLab. On GitHub, all the m3api libraries had two workflows, `test` and `release`. On GitLab, this corresponds to two stages with the same names. As of 2025-08-22, all the work related to this ticket is only on GitLab (not on GitHub), in repositories named “tmp-m3api*” (non-tmp repositories will be created only when everything is ready), on the `main` branch. Current status: - [m3api](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api): Contains a `.gitlab-ci-template.yml` file, with [hidden jobs](https://docs.gitlab.com/ci/jobs/#hide-a-job) used to template the CI in all libraries, and a `.gitlab-ci.yml` with the specific CI for the main m3api library (importing and extending the templates). - `test-job`, `test-package-lock-job` (imported from the template file), and `test-types-job` cover all the jobs in `.github/workflows/test.yaml`. - `release-job`, `publish-job`, and `doc-job` (all imported from the template file) cover all the jobs in `.github/workflows/release.yaml`. As mentioned in T392290#10782968, the order of operations is slightly different: there’s no support for triggering CI when a release is created; rather, `release-job` creates the release itself, while `publish-job` pushes it to npm (corresponds to GitHub’s `release` job). - TODO: `release-job` currently works around T333161 using a custom, non-WMCS image (the first option in T333161#10784529); clarify if this is okay and/or check if it still works with `tag: wmcs`. - Status: **complete**, I think, except for actually pushing docs to doc.w.o (blocked on {T392716}). - [m3api-botpassword](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api-botpassword): Contains a `.gitlab-ci.yml` file importing and extending the templates. - `test-job` and `test-package-lock-job` cover all the jobs in `.github/workflows/test.yaml`. `test-job` is tagged `wmcs` as part of T397591; according to T397591#10939598 this was at some point not strictly necessary, but still seems generally nice. TODO: Check if this tag should perhaps be moved into the templates. (But not the potential conflict with `release-job` mentioned above.) - `release-job`, `publish-job` and `doc-job` cover all the jobs in `.github/workflows/release.yaml`, nothing special here. - Status: **complete** except for the TODO, I think. - [m3api-query](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api-query): Contains a `.gitlab-ci.yml` file importing and extending the templates. - The same five jobs cover the same two workflows. Nothing special here whatsoever, I think. - Status: **complete**. - m3api-oauth2: Nothing so far. - m3api-oauth2’s GitHub CI uses yours truly’s [setup-mediawiki](https://github.com/lucaswerkmeister/setup-mediawiki/) action to run tests against a CI-local MediaWiki install with an artificially lowered `$wgOAuth2GrantExpirationInterval` (see T374562). I expect I’ll have to port this to GitLab CI myself, which will be a bit annoying but should be doable (IIRC I put together the original action in a couple of hours).

As part of migrating m3api off of GitHub, all the current CI needs to be ported to GitLab. On GitHub, all the m3api libraries had two workflows, `test` and `release`. On GitLab, this corresponds to two stages with the same names. As of 2025-08-22, all the work related to this ticket is only on GitLab (not on GitHub), in repositories named “tmp-m3api*” (non-tmp repositories will be created only when everything is ready), on the `main` branch. Current status: - [m3api](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api): Contains a `.gitlab-ci-template.yml` file, with [hidden jobs](https://docs.gitlab.com/ci/jobs/#hide-a-job) used to template the CI in all libraries, and a `.gitlab-ci.yml` with the specific CI for the main m3api library (importing and extending the templates). - `test-job`, `test-package-lock-job` (imported from the template file), and `test-types-job` cover all the jobs in `.github/workflows/test.yaml`. - `release-job`, `publish-job`, and `doc-job` (all imported from the template file) cover all the jobs in `.github/workflows/release.yaml`. As mentioned in T392290#10782968, the order of operations is slightly different: there’s no support for triggering CI when a release is created; rather, `release-job` creates the release itself, while `publish-job` pushes it to npm (corresponds to GitHub’s `release` job). - TODO: `release-job` currently works around T333161 using a custom, non-WMCS image (the first option in T333161#10784529); clarify if this is okay and/or check if it still works with `tag: wmcs`. - Status: **complete**, I think, except for actually pushing docs to doc.w.o (blocked on {T392716}). - [m3api-botpassword](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api-botpassword): Contains a `.gitlab-ci.yml` file importing and extending the templates. - `test-job` and `test-package-lock-job` cover all the jobs in `.github/workflows/test.yaml`. `test-job` is tagged `wmcs` as part of T397591; according to T397591#10939598 this was at some point not strictly necessary, but still seems generally nice. TODO: Check if this tag should perhaps be moved into the templates. (But not the potential conflict with `release-job` mentioned above.) - `release-job`, `publish-job` and `doc-job` cover all the jobs in `.github/workflows/release.yaml`, nothing special here. - Status: **complete** except for the TODO, I think. - [m3api-query](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api-query): Contains a `.gitlab-ci.yml` file importing and extending the templates. - The same five jobs cover the same two workflows. Nothing special here whatsoever, I think. - Status: **complete**. - m3api-oauth2: Nothing so far. - m3api-oauth2’s GitHub CI uses yours truly’s [setup-mediawiki](https://github.com/lucaswerkmeister/setup-mediawiki/) action to run tests against a CI-local MediaWiki install with an artificially lowered `$wgOAuth2GrantExpirationInterval` (see T374562). I expect I’ll have to port this to GitLab CI myself, which will be a bit annoying but should be doable (IIRC I put together the original action in a couple of hours).