Page MenuHomePhabricator
Create Task
Maniphest T277507

Core subproject commits aren't updated for backports if wmf branch commit has not yet been merged.
Closed, ResolvedPublic
Actions

Description

When a branch commit to core has not yet been merged, backports to a submodule's wmf branch won't end up with a corresponding update to the subproject commit hash in core. On that occasion, the backport commiter must then manually update the subproject commit and merge it into the wmf branch.

For example, this commit was merged into branch wmf/1.36.0-wmf.34, but since the core wmf/1.36.0-wmf.34 branch commit had not yet been merged, then the subproject commit did not get updated.

Can this be fixed so that the subproject commit doesn't have to be manually updated? The alternative of waiting until the branch commit has been merged means that the backport commiter must keep watching the branch commit patch.

Related Objects

Event Timeline

jeena created this task.Mar 15 2021, 8:30 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 15 2021, 8:30 PM
jeena edited projects, added Release-Engineering-Team; removed Release-Engineering-Team-TODO.Mar 15 2021, 8:31 PM
kostajh subscribed.Mar 15 2021, 9:01 PM
Jdforrester-WMF subscribed.Mar 15 2021, 9:04 PM

At this point I think the easiest option would be for the TrainBranchBot's commit to be auto-C+2'ed. There's still a few minutes of problem, but it'd be very rare.

jeena updated the task description. (Show Details)Mar 16 2021, 12:17 AM
DannyS712 subscribed.EditedMar 16 2021, 1:08 AM

Its not really important, but the time between the bot uploading the commit and the deployers merging it is when I sneak in and update the commit message to reference the weekly train blocker task (though there appears to be code in the make-release tool to automatically add these to the commit messages, it doesn't appear to be being used, https://github.com/wikimedia/mediawiki-tools-release/commit/20d4f0cdef4ee1f6b5f527f70f0a105a40e93404)

thcipriani triaged this task as Medium priority.Mar 16 2021, 4:08 PM
thcipriani edited projects, added Release-Engineering-Team-TODO (2021-01-01 to 2021-03-31 (Q3)), Release-Engineering-Team (Deployment services); removed Release-Engineering-Team, Release Pipeline.
thcipriani moved this task from INBOX to Maintenance on the Release-Engineering-Team-TODO (2021-01-01 to 2021-03-31 (Q3)) board.
brennen subscribed.Mar 16 2021, 4:09 PM

At this point I think the easiest option would be for the TrainBranchBot's commit to be auto-C+2'ed. There's still a few minutes of problem, but it'd be very rare.

Yeah, and we could probably document "make sure the commit has landed" easier than we can communicate that people need to coordinate this kind of thing with the train deployer. Offhand, I cannot think of any downsides to doing this as long as we update the docs.

• Urbanecm added a comment.Mar 17 2021, 3:02 PM
In T277507#6915689, @Jdforrester-WMF wrote:

At this point I think the easiest option would be for the TrainBranchBot's commit to be auto-C+2'ed. There's still a few minutes of problem, but it'd be very rare.

I agree with this solution. It's the one with least downsides, at least for me.

In T277507#6917855, @brennen wrote:

At this point I think the easiest option would be for the TrainBranchBot's commit to be auto-C+2'ed. There's still a few minutes of problem, but it'd be very rare.

Yeah, and we could probably document "make sure the commit has landed" easier than we can communicate that people need to coordinate this kind of thing with the train deployer. Offhand, I cannot think of any downsides to doing this as long as we update the docs.

Which documentation are you talking about, please?

brennen added a comment.Mar 17 2021, 3:36 PM

Which documentation are you talking about, please?

There's... A lot of deployment documentation, and it is scattered across a number of pages.

Please see T273802 for current thinking about changes needed there.

For this problem specifically, I think it would be relevant on at least:

...but I would like to reorganize things well enough that it can live in one well-defined place.

thcipriani mentioned this in T278343: 1.36.0-wmf.37 deployment blockers.Mar 30 2021, 5:28 PM
• mmodell subscribed.Mar 30 2021, 5:45 PM
In T277507#6915689, @Jdforrester-WMF wrote:

At this point I think the easiest option would be for the TrainBranchBot's commit to be auto-C+2'ed. There's still a few minutes of problem, but it'd be very rare.

Agreed, I think this is the way to go as well.

• mmodell awarded a token.Mar 30 2021, 5:45 PM
In T277507#6916205, @DannyS712 wrote:

Its not really important, but the time between the bot uploading the commit and the deployers merging it is when I sneak in and update the commit message to reference the weekly train blocker task (though there appears to be code in the make-release tool to automatically add these to the commit messages, it doesn't appear to be being used, https://github.com/wikimedia/mediawiki-tools-release/commit/20d4f0cdef4ee1f6b5f527f70f0a105a40e93404)

Indeed there is code to look it up (which should be mostly reliable though not well tested) ... we should make this happen automatically

Jdforrester-WMF added a comment.Apr 1 2021, 11:46 PM
In T277507#6917855, @brennen wrote:

At this point I think the easiest option would be for the TrainBranchBot's commit to be auto-C+2'ed. There's still a few minutes of problem, but it'd be very rare.

Yeah, and we could probably document "make sure the commit has landed" easier than we can communicate that people need to coordinate this kind of thing with the train deployer. Offhand, I cannot think of any downsides to doing this as long as we update the docs.

Filed as T278993: Automate the merge of the weekly branch cut.

In T277507#6957703, @mmodell wrote:
In T277507#6916205, @DannyS712 wrote:

Its not really important, but the time between the bot uploading the commit and the deployers merging it is when I sneak in and update the commit message to reference the weekly train blocker task (though there appears to be code in the make-release tool to automatically add these to the commit messages, it doesn't appear to be being used, https://github.com/wikimedia/mediawiki-tools-release/commit/20d4f0cdef4ee1f6b5f527f70f0a105a40e93404)

Indeed there is code to look it up (which should be mostly reliable though not well tested) ... we should make this happen automatically

Filed as T278994: Automatically tag the release task in the commit message of the weekly branch cut.

thcipriani edited projects, added Release-Engineering-Team-TODO (2021-04-01 to 2021-06-30 (Q4)); removed Release-Engineering-Team-TODO (2021-01-01 to 2021-03-31 (Q3)).Apr 20 2021, 12:37 AM
thcipriani removed a project: Release-Engineering-Team (Deployment services).Apr 20 2021, 1:10 AM
thcipriani edited projects, added Release-Engineering-Team (Doing); removed Release-Engineering-Team-TODO (2021-04-01 to 2021-06-30 (Q4)).Apr 20 2021, 4:25 AM
thcipriani closed this task as Resolved.Apr 20 2021, 4:49 PM
thcipriani assigned this task to dduvall.
thcipriani added subscribers: dduvall, thcipriani.
In T277507#6915689, @Jdforrester-WMF wrote:

At this point I think the easiest option would be for the TrainBranchBot's commit to be auto-C+2'ed. There's still a few minutes of problem, but it'd be very rare.

@dduvall did this!

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits