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-24, most of 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: - [ci-templates](https://gitlab.wikimedia.org/repos/m3api/ci-templates): Contains `test+release.yml` and `mediawiki.yml` files with [hidden jobs](https://docs.gitlab.com/ci/jobs/#hide-a-job) used to template the CI in all libraries. This is the only non-tmp repository so far. - `.test-job` and `.test-package-lock-job` cover the jobs in most repositories’ `.github/workflows/test.yaml`. - `.release-job`, `.publish-job`, and `.doc-job` cover all the jobs in the repositories’ `.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). - Status: **Mostly complete** except for {T392716}. - [m3api](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api): Contains a `.gitlab-ci.yml` importing and extending the templates. - In addition to `test-job` and `test-package-lock-job` (from the templates), there’s also a custom `test-types-job` to cover the rest of `.github/workflows/test.yaml`. - Status: **complete**. - [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`. - `release-job`, `publish-job` and `doc-job` cover all the jobs in `.github/workflows/release.yaml`, nothing special here. - Status: **complete**. - [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 `test-slow` job uses `mediawiki.yml` from the templates, a port of [setup-mediawiki](https://github.com/lucaswerkmeister/setup-mediawiki/), to run tests against a CI-local MediaWiki install with an artificially lowered `$wgOAuth2GrantExpirationInterval` (see T374562). - Status: **complete**. - [m3api](https://gitlab.wikimedia.org/repos/m3api) group-wide variables: - There are variables on the `m3api` group with credentials for different environments targeted by tests: `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.) - For the “publish” part, we’ll also need `$SECRET_NPM_TOKEN`, `$SECRET_GIT_TOKEN` and `$SECRET_SSH_KEY`: so far, these are only set on [tmp-m3api-example](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api-example), but they should probably all be org-wide. This is partially blocked on T392716 though (I don’t even know if an SSH key is the correct approach for pushing to doc.w.o). TODO. - Status: **partially complete**.

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-24, most of 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: - [ci-templates](https://gitlab.wikimedia.org/repos/m3api/ci-templates): Contains `test+release.yml` and `mediawiki.yml` files with [hidden jobs](https://docs.gitlab.com/ci/jobs/#hide-a-job) used to template the CI in all libraries. This is the only non-tmp repository so far. - `.test-job` and `.test-package-lock-job` cover the jobs in most repositories’ `.github/workflows/test.yaml`. - `.release-job`, `.publish-job`, and `.doc-job` cover all the jobs in the repositories’ `.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). - For now, `.doc-job` pushes the documentation both to the `doc` branch in the GitLab repository and to the `gh-pages` branch in the GitHub repository, so the documentation can still be hosted there. I’d like to move the documentation away from GitHub, but so far there’s been very little movement at {T392716}. - Status: **complete** (I no longer consider T392716 a blocker for this). - [m3api](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api): Contains a `.gitlab-ci.yml` importing and extending the templates. - In addition to `test-job` and `test-package-lock-job` (from the templates), there’s also a custom `test-types-job` to cover the rest of `.github/workflows/test.yaml`. - Status: **complete**. - [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`. - `release-job`, `publish-job` and `doc-job` cover all the jobs in `.github/workflows/release.yaml`, nothing special here. - Status: **complete**. - [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 `test-slow` job uses `mediawiki.yml` from the templates, a port of [setup-mediawiki](https://github.com/lucaswerkmeister/setup-mediawiki/), to run tests against a CI-local MediaWiki install with an artificially lowered `$wgOAuth2GrantExpirationInterval` (see T374562). - Status: **complete**. - [m3api](https://gitlab.wikimedia.org/repos/m3api) group-wide variables: - There are variables on the `m3api` group with credentials for different environments targeted by tests: `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.) - There are also variables on the `m3api` group with access tokens for publishing releases: `$GITHUB_ACCESS_TOKEN` (push to GitHub), `$GITLAB_ACCESS_TOKEN` (push to GitLab), and `$NPM_ACCESS_TOKEN` (publish to npm). - Status: **complete**.

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-24, most of 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: - [ci-templates](https://gitlab.wikimedia.org/repos/m3api/ci-templates): Contains `test+release.yml` and `mediawiki.yml` files with [hidden jobs](https://docs.gitlab.com/ci/jobs/#hide-a-job) used to template the CI in all libraries. This is the only non-tmp repository so far. - `.test-job` and `.test-package-lock-job` cover the jobs in most repositories’ `.github/workflows/test.yaml`. - `.release-job`, `.publish-job`, and `.doc-job` cover all the jobs in the repositories’ `.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). - Status: **Mostly complete** except for {T392716}For now, `.doc-job` pushes the documentation both to the `doc` branch in the GitLab repository and to the `gh-pages` branch in the GitHub repository, so the documentation can still be hosted there. I’d like to move the documentation away from GitHub, but so far there’s been very little movement at {T392716}. - Status: **complete** (I no longer consider T392716 a blocker for this). - [m3api](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api): Contains a `.gitlab-ci.yml` importing and extending the templates. - In addition to `test-job` and `test-package-lock-job` (from the templates), there’s also a custom `test-types-job` to cover the rest of `.github/workflows/test.yaml`. - Status: **complete**. - [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`. - `release-job`, `publish-job` and `doc-job` cover all the jobs in `.github/workflows/release.yaml`, nothing special here. - Status: **complete**. - [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 `test-slow` job uses `mediawiki.yml` from the templates, a port of [setup-mediawiki](https://github.com/lucaswerkmeister/setup-mediawiki/), to run tests against a CI-local MediaWiki install with an artificially lowered `$wgOAuth2GrantExpirationInterval` (see T374562). - Status: **complete**. - [m3api](https://gitlab.wikimedia.org/repos/m3api) group-wide variables: - There are variables on the `m3api` group with credentials for different environments targeted by tests: `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.) - For the “publish” part, we’ll also need `$SECRET_NPM_TOKEN`, `$SECRET_GIT_TOKEN` and `$SECRET_SSH_KEY`: so far, these are only set on [tmp-m3api-example](https://gitlab.wikimedia.org/repos/m3api/tmp-m3api-example), but they should probably all be org-wide.There are also variables on the `m3api` group with access tokens for publishing releases: `$GITHUB_ACCESS_TOKEN` (push to GitHub), This is partially blocked on T392716 though (I don’t even know if an SSH key is the correct approach for `$GITLAB_ACCESS_TOKEN` (pushing to doc.w.o).GitLab), TODOand `$NPM_ACCESS_TOKEN` (publish to npm). - Status: **partially complete**.