Opened 19 months ago

Closed 19 months ago

Last modified 19 months ago

#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):

https://codereview.adblockplus.org/29759555/

Description (last modified by tlucas)

Environment

Debian 9.4
Python 2.7
adblockpluschrome @ 8f77fc39cac3 (hg)

How to reproduce

  1. Follow this guide to setup a fresh release-testing environment
  2. 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.
  3. 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)

Change History (9)

comment:1 Changed 19 months ago by sebastian

  • Priority changed from Unknown to P3
  • Ready set

comment:2 Changed 19 months ago by tlucas

  • Description modified (diff)

comment:3 Changed 19 months ago by tlucas

  • Owner set to tlucas

comment:4 Changed 19 months ago by tlucas

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:5 Changed 19 months ago by tlucas

  • Description modified (diff)

comment:6 Changed 19 months ago by sebastian

  • Ready unset
  • Resolution set to rejected
  • Status changed from reviewing to closed

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.)

comment:7 Changed 19 months ago 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 19 months ago 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 19 months ago 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.

Note: See TracTickets for help on using tickets.