1943594 - push-to-releases don't support off-cycle partner repacks

Status: NEW

(Release Engineering :: Release Automation, defect, P3)

Description

[Johan Lorenzo [:jlorenzo] - PTO - Back August 24th]

Our docs about off-cycle partner repacks recommend to use off-cycle-parter-respin.py. This script uses a timestamp to populate the PARTNER_BUILDN. This build number is used in the candidates folder. For instance: v202501231439.

However, beetmover only considers v1 to be valid. This led beetmover to ignore these paths:

2025-01-24 08:58:38,317 - beetmoverscript.gcloud - DEBUG - Excluding partner repack pub/firefox/candidates/134.0.2-candidates/build1/partner-repacks/smi/smi-001/v202501231439/mac/en-GB/Firefox 134.0.2.dmg
2025-01-24 08:58:38,317 - beetmoverscript.gcloud - DEBUG - Excluding partner repack pub/firefox/candidates/134.0.2-candidates/build1/partner-repacks/smi/smi-001/v202501231439/win32/en-GB/Firefox Installer.exe
2025-01-24 08:58:38,317 - beetmoverscript.gcloud - DEBUG - Excluding partner repack pub/firefox/candidates/134.0.2-candidates/build1/partner-repacks/smi/smi-001/v202501231439/win32/en-GB/Firefox Setup 134.0.2.exe
2025-01-24 08:58:38,317 - beetmoverscript.gcloud - DEBUG - Excluding partner repack pub/firefox/candidates/134.0.2-candidates/build1/partner-repacks/smi/smi-001/v202501231439/win64/en-GB/Firefox Setup 134.0.2.exe

For the specific case of smi-001, I manually overrode the version to be v1. However, we need to make beetmover support any version number.

Comment 1

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:gabriel, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[[e-mail] (:bhearsum)]

I'm fairly certain the documented workaround of setting the build number to v1 doesn't work. I tried this for https://bugzilla.mozilla.org/show_bug.cgi?id=2059158 and push-to-release didn't copy anything at all.

Looking closer at what happened for smi-001 it looks like a v1 version of the repacks were generated minutes before being pushed to the releases directory. These have the same hashes as the v202501231439 ones, which suggest that the beetmover tasks were run again and republished the same repacks, and then the v1 copies were pushed to the releases directory. This doesn't line up at all with the idea of immediately cancelling the task group and specifically only re-running a couple of tasks that the docs talk about...

Comment 3

[[e-mail] (:bhearsum)]

Attachment: example action input for workaround

I managed to hack around this for https://bugzilla.mozilla.org/show_bug.cgi?id=2059158. Instead of following the steps in https://moz-releng-docs.readthedocs.io/en/latest/how-to/release/firefox/off-cycle-partner-repacks-and-funnelcake.html#shipping-partner-attributed-builds, I:

• Used the attached parameters to kick off a new ship phase (more on that below)
• Immediately cancelled the graph, which would've run things I didn't want it to
• Reran the release-partner-repack-beetmover tasks by hand; which copied the already built and tested builds into https://archive.mozilla.org/pub/firefox/candidates/153.0.1-candidates/build2/partner-repacks/kujtesa/kujtesa-001/v1/
• Reran firefox-push-to-release to copy the partner builds into releases
• Reran release-bouncer-aliases-firefox to update bouncer aliases

On the action input, there's a few key things:

• previous_graph_ids must contain the task group where the partner repacks were built with the dated build number. This ensures that new repacks aren't created.
• release_partner_build_number must be set to 1. This will make the beetmover and push-to-release tasks use v1 in the candidates paths
• rebuild_kinds must contain release-partner-repack-beetmover. This is also needed to ensure we don't build new repacks