update postrelease configs for DevEdition

RESOLVED FIXED

Status

P1
normal
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: bhearsum, Assigned: mtabara)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

MozReview Requests

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Updated

a year ago
Blocks: 1353825
(Reporter)

Updated

a year ago
No longer blocks: 1353821
(Assignee)

Updated

a year ago
Assignee: nobody → mtabara
Priority: -- → P1
(Assignee)

Comment 1

a year ago
* Publish to balrog stuff is tracked already in bug 1358614
* for version bump I'll push a fix in a bit
* mark as shipped task reuses the postrelease_firefox_beta which already exists in config.py and in-tree
* bouncer aliases reuses the bouncer_firefox_devedition.py which is already there from bug 1358613
Comment hidden (mozreview-request)
(Assignee)

Comment 3

a year ago
mozreview-review
Comment on attachment 8870857 [details]
Bug 1365595 - enable version bump in devedition.  a=release DONTBUILD

https://reviewboard.mozilla.org/r/142426/#review146018

::: mozilla/config.py:2434
(Diff revision 1)
>  }
>  BRANCHES['mozilla-beta']['postrelease_version_bump_config'] = {
>      "firefox": 'releases/postrelease_firefox_beta.py',
>      # configs are generic so can be reused
>      "fennec": 'releases/postrelease_firefox_beta.py',
> -    "devedition": "disabled",
> +    "devedition": 'releases/postrelease_firefox_beta.py',

Normally this should be a no-op as versiom bump will be done regardless by the beta build. However, I suppose the script will die with the current config - https://hg.mozilla.org/releases/mozilla-beta/file/tip/testing/mozharness/scripts/release/postrelease_version_bump.py#l25

We could as well at another variable in Release-Runner / config to enable/disable version bumping so that it's by default disabled for Dawn.
(Assignee)

Comment 4

a year ago
If I got all this wrong and that config change is not needed, we can close this. We're safe with configs for all the others.

Comment 5

a year ago
mozreview-review
Comment on attachment 8870857 [details]
Bug 1365595 - enable version bump in devedition.  a=release DONTBUILD

https://reviewboard.mozilla.org/r/142426/#review146024
Attachment #8870857 - Flags: review?(rail) → review+
(Assignee)

Comment 6

a year ago
So normally I'd uplift this patch to enabled version bump in devedition but ...
As I can see in the last graph of devedition, https://tools.taskcluster.net/task-group-inspector/#/5ZQ1F9PwTzeRTSoD71xGSw?_k=ay2949 the version bump task is not even scheduled (as opposed to other mark-release-as shipped or bouncer aliases) which is even better. I'm still not following how that happens. The version bump script is scheduled here[1] and that variable comes from here[2] which comes actually from config.py[3] which is set to "disabled". 

@rail: Is there a magic behind-the-scenes Jinja2 templating conditions I'm missing for "disabled" or how does that turn off that builder?

[1]: https://github.com/mozilla/releasetasks/blob/master/releasetasks/templates/desktop/release_graph.yml.tmpl#L211
[2]: https://hg.mozilla.org/build/tools/file/tip/buildfarm/release/release-runner.py#l400
[3]: https://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla/config.py#l2434
Flags: needinfo?(rail)
The behavior is controlled by postrelease_version_bump_enabled,see https://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla/config.py#l2471
Flags: needinfo?(rail)
(Assignee)

Comment 8

a year ago
(In reply to Rail Aliiev [:rail] ⌚️ET from comment #7)
> The behavior is controlled by postrelease_version_bump_enabled,see
> https://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla/config.
> py#l2471

Doh, "postrelease_version_bump_enabled" vs "postrelease_version_bump_config". This is what happens when you let me name these variables :)

"postrelease_version_bump_enabled" skips the schedule of the builder entirely so it doesn't matter what we have in the configs for "postrelease_version_bump_config". Could be as well "disabled" or anything else.

Closing this, all done. Mea culpa for confusion.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.