Page MenuHomePhabricator

[12h] Decide on the "secondary" CI for Wikibase code repository
Closed, ResolvedPublic

Description

Currently Wikibase CI run on WMF Jenkins is "augmented" by running php unit tests in a variety of additional configurations (e.g. non-English wiki, repo/client-only environment, etc) on legacy Travis CI infrastructure (travis-ci.org) - via github mirror of Gerrit code repository, see https://travis-ci.org/github/wikimedia/Wikibase.

travis-ci.org service is going to stop on Dec 31st 2020 (https://docs.travis-ci.com/user/migrate/open-source-repository-migration#q-when-will-the-migration-from-travis-ciorg-to-travis-cicom-be-completed), when all github repositories that are supposed to continue using Travis CI should be migrated to travis-ci.com.

There are no significant technical issues preventing migrating Wikibase github mirror to travis-ci.com. However, the new billing policy of Travis CI (https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing) would in practice mean that Wikibase CI jobs would not be run on travis-ci.com, or only run in limited extent.

It looks like the "credit" balance of github.com/wikimedia on Travis CI has already been used in November.
https://travis-ci.com/github/wikimedia displays the message "Builds have been temporarily disabled for private and public repositories due to a negative credit balance. Please go to the Plan page to replenish your credit balance."

Incomplete list of options includes:

  1. migrating additional CI for Wikibase to some other CI infrastructure, e.g. Github Actions
  2. negotiating with the WMF changing the Travis CI plan to a paid one which would an unlimited/less limited resources available
  3. migrate additional CI for Wikibase to additional jobs on WMF Jenkins CI

Dropping the extended CI testing is not considered an option unless arguments are provided for it serving no purpose.

Note for camp: this should probably be a timeboxed investigation resulting in an ADR that's open to the whole team. timeboxed at 12 hours.

Acceptance criteria:

  • Decision on how to continue with the "Secondary" CI for Wikibase has been recorded on the ticket, and, if applicable, as an ADR in Wikibase git repository
  • Tasks have been created for WMDE Engineering team to execute the decision

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Prio Session Notes: We stuck this straight at the top as it is time sensitive and the decision should actively be made asap even if it is then decided that we don't need to do the work now

noarave renamed this task from Decide on the "secondary" CI for Wikibase code repository to [12h] Decide on the "secondary" CI for Wikibase code repository.Dec 15 2020, 2:10 PM
noarave updated the task description. (Show Details)

The main use of the Travis CI that I can remember is that it uses wikis with non-English content languages, so occasionally it flags up that we’ve unintentionally written a test which relies on $wgLanguageCode = "en". But I don’t see why we couldn’t set different language codes for some of our Jenkins jobs.

The main use of the Travis CI that I can remember is that it uses wikis with non-English content languages, so occasionally it flags up that we’ve unintentionally written a test which relies on $wgLanguageCode = "en". But I don’t see why we couldn’t set different language codes for some of our Jenkins jobs.

Additionally in the past(?) sometimes certain extensions were disabled in our (or all?) Jenkins jobs (can't exactly recall why, maybe due to performance?), but our Travis setup always remained fairly constant. Nevertheless setting different languages on WMF CI sounds like a good idea, but out of scope for this.

As far as I can tell, the Travis CI features we use are:

  • PHP installed (multiple versions)
  • MySQL running
  • notifications via
    • email
    • IRC
  • composer cache

I think all of them are available on GitHub Actions:

Apart from that, most of our Travis CI is a collection of shell scripts, which I hope will mostly work the same under GitHub Actions. So I think that migrating to GitHub Actions could be a relatively low-effort solution for the short or mid term; in the long term, the Wikimedia migration to GitLab will presumably change a lot about CI anyways.

For what it is worth, I would not see IRC notifications as a hard requirement for WMDE at this point. Notifications on channels other than an email is something we might want to look into at some point, but I wouldn't care about "feature parity" in IRC case (unless it comes out of the box without any effort).

Change 654640 had a related patch set uploaded (by Silvan Heintze; owner: Silvan Heintze):
[mediawiki/extensions/Wikibase@master] Add ADR-16

https://gerrit.wikimedia.org/r/654640

Change 654640 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Add ADR-16

https://gerrit.wikimedia.org/r/654640

Change 656882 had a related patch set uploaded (by Noa wmde; owner: Noa wmde):
[mediawiki/extensions/Wikibase@master] Accept ADR-0016: migrate secondary CI to Github actions

https://gerrit.wikimedia.org/r/656882

Change 656882 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Accept ADR-0016: migrate secondary CI to Github actions

https://gerrit.wikimedia.org/r/656882

noarave added a subscriber: noarave.

This is going to test verification so we don't forget about the required follow up task :)

Second task created and I have added it straight to the backlog for camp.
I actually think the task created should probably just pop to the top of TODO on the campsite and be tackled, rather than once again going through story time, task breakdown etc.
In other words this time boxed investigation should have just been a task split out from the "story"