1591591 - Change the app.statusContext configuration for github.com/apps/community-tc-integration

Status: RESOLVED FIXED

(Taskcluster :: Services, enhancement)

Description

[Simon Sapin (:SimonSapin)]

Servo has automation (bors a.k.a. homu) that automatically merges pull requests when CI reports that tests pass. This is based on GitHub Status API. Results from multiple CI systems (Travis-CI, AppVeyor, Taskcluster, …) are distinguished based on the context string in Statuses.

For migrating (bug 1574648) of Servo to the community-tc deployment we’ll likely want to have a both https://github.com/apps/taskcluster and https://github.com/apps/community-tc-integration enabled at the same time on the same repository, each reporting a Status on the same commit in reaction e.g. to a given push event.

To be able to tell these two Status entries apart, they should ideally have different context string. My reading of handlers.js is that (part of) this string is based on the app.statusContext string in the configuration of the integration service.

To avoid breaking the existing/legacy integration, I’d prefer the new one (community-tc) to change, if it doesn’t already have a different string configured.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

https://github.com/taskcluster/taskcluster/pull/1869

I've set APPLICATION_NAME in the Heroku deployment to "Taskcluster", so the existing integration's behavior should not change. The new one will be "Community-TC".

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

I'll see if I can get an expedited review here and make a release Monday morning. Cloudops does the releases, and will need to do a minor bit of adjustment, so I would hope for deployment mid-day pacific time.

Comment 3

[Simon Sapin (:SimonSapin)]

Sorry for the churn, especially now that https://github.com/taskcluster/taskcluster/pull/1869 has already landed, but now I’m wondering if it’d be better not to deploy this change (and revert it on GitHub).

I’ve just realized that tc-github does not set any "status" when expanding .taskcluster.yml results in an empty tasks array. So we could enable both deployments on the same repo and use mutually-conditionals in .taskcluster.yml so that at most one on the deployments sets a status for any given GitHub event. Keeping the same context string is even somewhat an advantage in that it simplifies homu’s configuration.

Also, changing the context string might be disruptive to other projects that have already migrated and use homu-like tooling that relies on the context string.

Comment 4

[Simon Sapin (:SimonSapin)]

Please disregard comment 3. It was an idea for an alternative plan but a chat with Dustin on IRC convinced me to continue as we had planned earlier.

Comment 5

[Simon Sapin (:SimonSapin)]

This has been deployed. See for example https://github.com/servo/servo/pull/24652 which has statuses for both Community-TC (pull_request) and Taskcluster (pull_request). Thanks!