Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#4355 closed defect (fixed)

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

Reported by: fhd Assignee: tlucas
Priority: P3 Milestone:
Module: Automation Keywords:
Cc: sebastian, trev, kvas Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by tlucas)


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 -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
  • 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
  • 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:
    • ./ -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:
    • ./ -t chrome release -k <path_to_new_key.pem> 1.2.4 (this should fail now)

Change History (10)

comment:1 Changed 4 years ago by sebastian

  • Cc trev kvas added
  • Priority changed from Unknown to P3
  • Ready set

comment:2 Changed 3 years ago by tlucas

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

comment:3 Changed 3 years ago by tlucas

  • Owner set to tlucas

comment:4 Changed 3 years ago by tlucas

  • Description modified (diff)

comment:5 Changed 3 years ago by tlucas

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

comment:6 Changed 3 years ago by tlucas

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

comment:7 Changed 3 years ago by tlucas

  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:8 Changed 3 years ago by tlucas

  • Description modified (diff)

comment:9 Changed 3 years ago by tlucas

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

comment:10 Changed 3 years ago by tlucas

  • Description modified (diff)
Note: See TracTickets for help on using tickets.