We enabled this for devedition + firefox, but not fennec. We're missing a bunch of files to do so.

Not sure about the depend signing cert stuff, also need to make sure these files exist in-tree.

This passes travis: https://travis-ci.org/escapewindow/build-buildbot-configs/builds/286768813?utm_source=github_status&utm_medium=notification Do you know what we should do about the depend signature stuff? Will it matter? Essentially, right now maple is signing with the dep key. If we can continue making things work with the dep key, we are that much closer to staging releases on try. If that's too hard or time consuming, we can switch to release-signing and leave staging-releases-on-try for later.

Comment on attachment 8917601 [details] [diff] [review] bb-c.diff Review of attachment 8917601 [details] [diff] [review]: ----------------------------------------------------------------- I don't think we rely on any signing stuff in Fennec release automation.

Comment on attachment 8917599 [details] [diff] [review] maple-configs.diff Review of attachment 8917599 [details] [diff] [review]: ----------------------------------------------------------------- lgtm

Based off https://github.com/mozilla-releng/beetmoverscript/blob/master/requirements-prod.txt + beetmoverscript 2.0.0. This patch works on beetmover-dev1 atm. Sorry about the whitespace diff that makes every line change.

This, along with a version bump to land https://github.com/mozilla-releng/beetmoverscript/pull/89 , should get fennec beetmover candidates green again :)

Comment on attachment 8921591 [details] [diff] [review] fix_beetmover2.diff + commented addressed in PR.

Rail - we have next_version defined in payload properties on some non-version bumping tasks. Do you know if that will break?

(In reply to Aki Sasaki [:aki] from comment #9) > Rail - we have next_version defined in payload properties on some > non-version bumping tasks. > Do you know if that will break? Nope, none of them use that property. All good.

:garbas , we're both new to this, but does this look sane? When I diff an unpatched-maple and a patched-maple's output with ./mach taskgraph target-graph -p /src/gecko/params/maple-publish-fennec.yml --json I get 4197c4197,4199 < "dependencies": {}, --- > "dependencies": { > "fennec-push-to-cdns": "fennec-push-to-cdns" > }, And when I run ./mach taskgraph optimized -p /src/gecko/params/maple-publish-fennec.yml --json I actually see the taskId of the beetmover-cdns task populated in the version bump task dependencies. So I'm pretty sure this works.

Comment on attachment 8922671 [details] [diff] [review] dependencies :aki Sorry I only noticed today that you pinged me on friday. it always looks strange to me that we have to create new transforms. i would assume dependency handling would be already solved by task transform, since it is such a basic requirement. other then that i think the change looks good.