Change Details

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`. - There are variables on the `m3api` group with credentials for different environments: `MEDIAWIKI_PROD_BOT_USERNAME` + `MEDIAWIKI_PROD_BOT_PASSWORD` for Wikimedia production; `MEDIAWIKI_BETA_REAL_USERNAME` + `MEDIAWIKI_BETA_REAL_PASSWORD` for the beta cluster (actual user credentials, so m3api-oauth2 can log in in Selenium / WebdriverIO and approve an OAuth login); and `MEDIAWIKI_BETA_BOT_USERNAME` + `MEDIAWIKI_BETA_BOT_PASSWORD` also for the beta cluster (bot password). The tests don’t use these directly; instead, they’re mapped into the environment variables the tests expect by the different CI files. (I might clean this up later, but it makes the migration easier to not rename the variables in the tests at first. In GitHub they’re just CI variables with the same names but for different environments on each repository, which is pretty confusing.) - 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 note 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). - Status: **not yet started**.

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`. - There are variables on the `m3api` group with credentials for different environments: `MEDIAWIKI_PROD_BOT_USERNAME` + `MEDIAWIKI_PROD_BOT_PASSWORD` for Wikimedia production; `MEDIAWIKI_BETA_REAL_USERNAME` + `MEDIAWIKI_BETA_REAL_PASSWORD` for the beta cluster (actual user credentials, so m3api-oauth2 can log in in Selenium / WebdriverIO and approve an OAuth login); `MEDIAWIKI_BETA_BOT_USERNAME` + `MEDIAWIKI_BETA_BOT_PASSWORD` also for the beta cluster (bot password); and `MEDIAWIKI_BETA_OAUTH_CLIENT_ID` + `MEDIAWIKI_BETA_OAUTH_CLIENT_SECRET` + `MEDIAWIKI_BETA_OAUTH_NONCONFIDENTIAL_CLIENT_ID` + ``MEDIAWIKI_BETA_OAUTH_NONCONFIDENTIAL_CLIENT_SECRET` still for the beta cluster (OAuth client ID + secret, regular and non-confidential). The tests don’t use these directly; instead, they’re mapped into the environment variables the tests expect by the different CI files. (I might clean this up later, but it makes the migration easier to not rename the variables in the tests at first. In GitHub they’re just CI variables with the same names but for different environments on each repository, which is pretty confusing.) - TODO: Consider specifying a default image explicitly in `.gitlab-ci-template.yml` instead of relying on the Wikimedia GitLab default (currently `releng/node18-test`). m3api-oauth2 needs to use a different “flavor” of the image (`releng/node18-test-browser`), and I think I’d rather make sure we use the same Node version everywhere than have Wikimedia GitLab update under us and end up testing a combination of Node 18/20/etc. (Also, we claim compatibility with Node 18 and it would be nice to continue testing that.) - Status: **complete**, I think, except for actually pushing docs to doc.w.o (blocked on {T392716}), and the TODOs mentioned above. - [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 note 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](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api-oauth2): Contains a `.gitlab-ci.yml` file importing and extending the templates. - The regular `test` job works, running browser tests against the beta cluster (using the `releng/node18-test-browser` image for this). The same caveat wrt the potential `wmcs` tag as for m3api-botpassword probably applies here as well. (At the moment, it seems to work fine from the default runners.) - The `test-slow` job is still TBD. 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). - Status: **work in progress**.

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`. - There are variables on the `m3api` group with credentials for different environments: `MEDIAWIKI_PROD_BOT_USERNAME` + `MEDIAWIKI_PROD_BOT_PASSWORD` for Wikimedia production; `MEDIAWIKI_BETA_REAL_USERNAME` + `MEDIAWIKI_BETA_REAL_PASSWORD` for the beta cluster (actual user credentials, so m3api-oauth2 can log in in Selenium / WebdriverIO and approve an OAuth login); and `MEDIAWIKI_BETA_BOT_USERNAME` + `MEDIAWIKI_BETA_BOT_PASSWORD` also for the beta cluster (bot password); and `MEDIAWIKI_BETA_OAUTH_CLIENT_ID` + `MEDIAWIKI_BETA_OAUTH_CLIENT_SECRET` + `MEDIAWIKI_BETA_OAUTH_NONCONFIDENTIAL_CLIENT_ID` + ``MEDIAWIKI_BETA_OAUTH_NONCONFIDENTIAL_CLIENT_SECRET` still for the beta cluster (OAuth client ID + secret, regular and non-confidential). The tests don’t use these directly; instead, they’re mapped into the environment variables the tests expect by the different CI files. (I might clean this up later, but it makes the migration easier to not rename the variables in the tests at first. In GitHub they’re just CI variables with the same names but for different environments on each repository, which is pretty confusing.) - TODO: Consider specifying a default image explicitly in `.gitlab-ci-template.yml` instead of relying on the Wikimedia GitLab default (currently `releng/node18-test`). m3api-oauth2 needs to use a different “flavor” of the image (`releng/node18-test-browser`), and I think I’d rather make sure we use the same Node version everywhere than have Wikimedia GitLab update under us and end up testing a combination of Node 18/20/etc. (Also, we claim compatibility with Node 18 and it would be nice to continue testing that.) - Status: **complete**, I think, except for actually pushing docs to doc.w.o (blocked on {T392716}), and the TODOs mentioned above. - [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 note 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](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api-oauth2): Contains a `.gitlab-ci.yml` file importing and extending the templates. - The regular `test` job works, running browser tests against the beta cluster (using the `releng/node18-test-browser` image for this). The same caveat wrt the potential `wmcs` tag as for m3api-botpassword probably applies here as well. (At the moment, it seems to work fine from the default runners.) - The `test-slow` job is still TBD. 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). - Status: **not yet started**work in progress**.