Increase reliability of scap release process
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	dancy
	Mar 18 2021, 7:27 PM

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.

Details

Related Changes in Gerrit:

	Subject	Repo	Branch	Lines +/-
	Simplify RELEASE.md steps	mediawiki/tools/scap	master	+71 -134

Customize query in gerrit

Related Objects
Search...

Status	Assigned	Task
Resolved	• LarsWirzenius	T272145 Tag Scap release 1.37.1 and ask serviceops to deploy it to production
Resolved	dancy	T277793 Increase reliability of scap release process
Resolved	• LarsWirzenius	T269153 Applying security patches should be robust and also give some useful output

Event Timeline

dancy created this task.Mar 18 2021, 7:27 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 18 2021, 7:27 PM

dancy updated the task description. (Show Details)Mar 18 2021, 7:27 PM

thcipriani awarded a token.Mar 19 2021, 5:18 PM

Added T269153 as a subtask to indicate that this work should happen after the apply patches work.

thcipriani triaged this task as Medium priority.Mar 23 2021, 4:10 PM

thcipriani moved this task from Should be empty (use Release-Engineering-Team) to Next on the Release-Engineering-Team-TODO board.

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?

taavi subscribed.Mar 30 2021, 1:22 PM

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.

In T277793#6956593, @LarsWirzenius wrote:

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.

• LarsWirzenius added a parent task: T272145: Tag Scap release 1.37.1 and ask serviceops to deploy it to production.Mar 30 2021, 4:11 PM

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 :)