Opened on 04/21/2018 at 04:44:20 PM
Closed on 04/24/2018 at 06:30:22 PM
Last modified on 04/25/2018 at 04:35:38 PM
#6606 closed defect (rejected)
"build.py release" fails with "Detected incoming changesets in ..." when unimportant bookmarks are outdated
| Reported by: | tlucas | Assignee: | tlucas |
|---|---|---|---|
| Priority: | P3 | Milestone: | |
| Module: | Automation | Keywords: | |
| Cc: | sebastian, fhd | Blocked By: | |
| Blocking: | Platform: | Unknown / Cross platform | |
| Ready: | no | Confidential: | no |
| Tester: | Unknown | Verified working: | no |
| Review URL(s): | |||
Description (last modified by tlucas)
Environment
Debian 9.4
Python 2.7
adblockpluschrome @ 8f77fc39cac3 (hg)
How to reproduce
- Follow this guide to setup a fresh release-testing environment
- In the the fake remote of adblockpluschrome, commit some arbitrary changes into an arbitrary bookmark (e.g. next). This will simulate a situation in which the release engineer has the latest master locally, but did not yet upgrade the local copy of the bookmark next to the latest changes. This happens in codefreeze.
- Run the release for e.g. gecko:
$ build.py release -t gecko 3.0.5
Observed behaviour
The release fails with Detected incoming changesets in <your_repos_path>/adblockpluschrome
Expected behaviour
The release should succeed, despite differing contents in unimportant bookmarks (i.e. all but the locally active bookmark)
Attachments (0)
Change History (9)
comment:1 Changed on 04/21/2018 at 05:09:35 PM by sebastian
- Priority changed from Unknown to P3
- Ready set
comment:3 Changed on 04/22/2018 at 04:24:55 PM by tlucas
- Owner set to tlucas
comment:4 Changed on 04/23/2018 at 06:46:30 AM by tlucas
- Review URL(s) modified (diff)
- Status changed from new to reviewing
comment:6 Changed on 04/24/2018 at 06:30:22 PM by sebastian
- Ready unset
- Resolution set to rejected
- Status changed from reviewing to closed
comment:7 Changed on 04/25/2018 at 03:37:50 PM by fhd
That's fair enough. Just one thing: Could we currently release from a bookmark other than master? If yes, I don't think we need to change anything, really. If it's currently not possible, it'd be good if we could make that possible. I do see us having to do an emergency release out of a different branch at some point, and by definition that'd be an emergency then :)
comment:8 Changed on 04/25/2018 at 03:53:31 PM by sebastian
AFAIK we can (and already did in the past). The only thing is that development builds are generated out of the master (or edge or safari) bookmark. So we'd either have to change the configuration on the server temporarily in order to generate the development builds from another bookmark, or provide testers with manually created test builds, if we want to do an emergency release out of a different branch.
comment:9 Changed on 04/25/2018 at 04:35:38 PM by fhd
Yeah, that part is inconvenient, but I figure we can deal with it. Sounds like we don't really need to do anything here, indeed.
We don't know which branch is released from (e.g. it could be the edge bookmark, or we could have created an ad-hoc branch for an emergency release). So we cannot hard-code hg incoming -r master.
Essentially we are intereseted in incoming changes that are descendants of the current revision (i.e. hg log --rev .:: if those changes would already been pulled), however, hg incoming's --rev option doesn't support revision ranges, and implementing these semantics ourselves would be quite a hassle.
After all it doesn't seem to be a big deal if you have to call hg pull before the release even if all incoming changes are in unrelated branches. (Alternatively, we could remove the check for incoming changes altogether.)