Skip to content

Bug 2052985 - feat: add build_signing transform and artifact signing specs#237

Open
kryoseu wants to merge 1 commit into
mozilla-releng:mainfrom
kryoseu:feat-build-signing-transform
Open

Bug 2052985 - feat: add build_signing transform and artifact signing specs#237
kryoseu wants to merge 1 commit into
mozilla-releng:mainfrom
kryoseu:feat-build-signing-transform

Conversation

@kryoseu

@kryoseu kryoseu commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Port the desktop and source build-signing transforms (add_signed_routes, define_upstream_artifacts) and the shared generate_specifications_of_artifacts_to_sign helper from gecko_taskgraph so they can be consumed by both Gecko and comm.

Android signing is left out from generate_specifications_of_artifacts_to_sign. Consumers handle it before delegating here since it depends on gecko-specific scriptworker code (generate_beetmover_upstream_artifacts).

Port the desktop and source build-signing transforms
(add_signed_routes, define_upstream_artifacts) and the shared
generate_specifications_of_artifacts_to_sign helper from
gecko_taskgraph so they can be consumed by both Gecko and comm.

Android signing is left out; consumers handle it before delegating
here since it depends on gecko-specific scriptworker code.
@kryoseu
kryoseu force-pushed the feat-build-signing-transform branch from d1c2ace to af00c41 Compare July 13, 2026 18:48
@kryoseu kryoseu changed the title Bug 2052985 - feat: add build_signing transform and artifact signing … Bug 2052985 - feat: add build_signing transform and artifact signing Jul 13, 2026
@kryoseu kryoseu changed the title Bug 2052985 - feat: add build_signing transform and artifact signing Bug 2052985 - feat: add build_signing transform and artifact signing specs Jul 13, 2026
@kryoseu
kryoseu marked this pull request as ready for review July 13, 2026 22:29
@kryoseu
kryoseu requested a review from a team as a code owner July 13, 2026 22:29

@bhearsum bhearsum left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not certain how I feel about this. This is a forklift of existing gecko_taskgraph code into this repository, and it retains a lot of Gecko-isms. I don't want to let perfect by the enemy of good, but I would also prefer that we don't copy hacks into what we expect to be the long term home for this code.

I'm also not sure that I'm fond of the idea of putting the whole build_signing transform in here. That's a transform that is highly specialized, and unlikely to be generally useful, as it is very closely tied to a couple of specific kinds in gecko. A rename or possibly refactor of it might make me a little bit more comfortable with the idea.

One idea (which would also help in getting rid of some of the Gecko-isms) would be to not import this code as a transform, but pull out the core bits and have them called in transforms in both gecko and comm repositories. For example, the core bit of add_signed_routes is the inner-most for loop. Putting that in its own (pure) function would avoid the need for code here to know anything about the shippable attribute or enable-signing-routes.

I have some specific comments below, but I also think you may want to consider putting some of this code in comm instead of here. If you want a more immediate path forward, I strongly urge you to put the code you need into the comm repo for now.

enable_signing_routes = job.pop("enable-signing-routes", True)

job["routes"] = []
if dep_job.attributes.get("shippable") and enable_signing_routes:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shippable is a Gecko (and I guess comm) specific concept that doesn't belong here IMO.

job["routes"] = []
if dep_job.attributes.get("shippable") and enable_signing_routes:
for dep_route in dep_job.task.get("routes", []):
if not dep_route.startswith("index.gecko.v2"):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gecko in the index route is also Gecko specific. I'm not sure this would even work for comm in its current form?



def is_partner_kind(kind):
if kind and kind.startswith(("release-partner", "release-eme-free")):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are Gecko-isms that shouldn't live here (the same goes for names of other specific kinds).

return True


def generate_specifications_of_artifacts_to_sign(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function in particular I do not think should move here in its current form. It has...not aged well to say the least, and I would prefer not to prolong its life.

@jcristau jcristau left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with Ben that this shouldn't be moved, or not as-is.

@ahal

ahal commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

I think it's worth stepping back and discussing what actually is the thing we want to share across all projects here. When it comes to signing, the mechanism we use is the signingscript workers. These workers have a schema that all task payloads must conform to.

In gecko (and comm), the thing that makes task payloads conform to the schema is already in mozilla-taskgraph:

def build_signing_payload(config, task, task_def):

So instead of copy/pasting transforms, I think the question we want to ask is what logic would make sense to tease out of the various signing transforms (across gecko, comm, and even other repos) and place into build_signing_payload instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants