Chrome/Opera/Safari release automation fails if the local copy of the downloads repository is outdated

[fhd]

Environment

This happened during the Adblock Plus for Chrome/Opera/Safari 1.12.2 release, base revision was 44641c853190.

How to reproduce

1. Clone the adblockpluschrome and downloads repositories. Important: Make sure to configure different remotes than the central upstream repositories (i.e. local copies of the repositories), the release automation automatically pushes changes.
2. Update the downloads working directory to an arbitrary older revision and strip all changes following that revision. (This simulations the situation where you have an older version of the downloads repository locally.)
3. In the adblockpluschrome working directory, run build.py -t chrome release -k adblockpluschrome.pem -k adblockplussafari.pem 1.12.2 to perform the 1.12.2 release. (The version number you use doesn't matter.)

Observed behaviour

The script runs into an error when attempting to push to the remote downloads repository, because it adds a new build locally and commits it without attempting to pull first.

Expected behaviour

The release automation should deal with this situation without failing. I'm not sure what's the best way of dealing with this, I see two options:

Before making any changes, the release automation should check whether the involved repositories, which are not listed in the dependencies-list, are outdated (or dirty, see #4354) and abort with an error message.

Hints for testers

To run the releaseAutomation locally, you can follow these steps (Assuming there is no local copy of the repositories yet):

• Clone the adblockpluschrome repository to a location of your choice hg clone https://hg.adblockplus.org/adblockpluschrome
• Clone the downloads repository to a location of your choice (i suggest the same location as abp-chrome - otherwise you would have to specify the downloads location in the build process) hg clone https://hg.adblockplus.org/downloads
• Create the fake remotes for adblockpluschrome and downloads:
  • cp -ar adblockpluschrome abpc_remote
  • cp -ar downloads downloads_remote
  • Configure your main repositories to have the fake remotes as remotes: edit .hg/hgrc in both main repositories to contain default = <path_to_fake_remote> e.g.: default = /home/tlucas/abp/tmphg/abpc_remote
  • you can verify this by running hg incoming in the main repositories, it should say "comparing with <your_fake_remote>"

To test this issue, you can proceed with the following steps:

• Create your own .pem (this requires openssl to be installed) in a location of your choice:
  • openssl req -newkey rsa:2048 -nodes -x509 -days 365 -out certificate.pem - additionally to certificate.pem, this creates a key.pem, which is the file we need
• run the release in your adblockpluschrome main repository:
  • ./build.py -t chrome release -k <path_to_new_key.pem> 1.2.4 (this should work)
• reset your main downloads repository to have an outdated revision: hg strip tip
• run the release in your adblockpluschrome main repository:
  • ./build.py -t chrome release -k <path_to_new_key.pem> 1.2.4 (this should fail now)

[tlucas]

As discussed with Wladimir, we won't attempt any automatic pulls but instead bail out early with an appropriate error-message.

[tlucas]

A commit referencing this issue has landed:
​Issue 4354, 4355 - handle dirty/outdated repos on release

[tlucas]

Please note: The patch introduced a regression, which is handled in #5736