Page MenuHomePhabricator

Increase reliability of scap release process
Closed, ResolvedPublic

Description

The current scap release process (as described in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/tools/scap/+/master/RELEASE.md) has some issues:

  • It requires performing a merge from 'master' into an infrequently-updated 'release' branch. This step is very likely to require manual conflict resolution which is error-prone (e.g, resulting in problems like that identified in T277782).
  • It recommends pushing to Gerrit in a way that does not generate reviewable patchsets. When trying to investigate these commits in the future, they do not show up in the Gerrit UI which can be confusing.

Proposed changes:

  • Get rid of the 'release' branch. Instead, tag a commit in the master branch and supply that tag to SRE when we ask them to build the package. No merging required. Just a point-in-time reference to what we want to be packaged.
  • Revise all steps that suggest pushing to Gerrit without generating patchsets. If there are problems with going through the normal Gerrit/CI workflows then we need to fix them.

Event Timeline

I agree that the current Scap release process is sub-optimal. My preference would be to move to a process where the "master" branch is always as close to releasable as possible. Ideally the only things from preventing it from being released should be:

  • updating debian/changelog
  • setting the version (scap/version.py)
  • creating a git tag

The first two should be handled in the normal process (push change to Gerrit for review, have someone CR+2 the change, and let CI merge it). My understanding is that the tag can't go via Gerrit review and needs to be pushed directly, but if it can be reviewed, all the better.

@jijiki do you object to this?

To make sure: I would expect that every commit in the "master" branch could be built into a .deb using a standard process. If that's not the case at some point, I think we need to fix it pronto. If SRE needs to make changes to Scap during the release building, I would like to hear about that.

I agree that the current Scap release process is sub-optimal. My preference would be to move to a process where the "master" branch is always as close to releasable as possible. Ideally the only things from preventing it from being released should be:

  • updating debian/changelog
  • setting the version (scap/version.py)
  • creating a git tag

The first two should be handled in the normal process (push change to Gerrit for review, have someone CR+2 the change, and let CI merge it). My understanding is that the tag can't go via Gerrit review and needs to be pushed directly, but if it can be reviewed, all the better.

@jijiki do you object to this?

Adding serviceops-radar for advice from serviceops folks.

I think this is mostly what works for Release-Engineering-Team best. Since we are packaging scap, we will be happy with a step by step documented process of how to build the debian package on our build host. The guide I follow to build it is https://wikitech.wikimedia.org/wiki/Scap3#Production_Upgrade, please update accordingly :)

Change 721351 had a related patch set uploaded (by Ahmon Dancy; author: Ahmon Dancy):

[mediawiki/tools/scap@master] RELEASE.md updates

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

Change 721351 merged by jenkins-bot:

[mediawiki/tools/scap@master] Simplify RELEASE.md steps

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

dancy claimed this task.