| commit | 87df76ada8d0f1dc4bbe156b6807eb5824592751 | [log] [tgz] |
|---|---|---|
| author | Oliver Newman <olivernewman@fuchsia.infra.roller.google.com> | Tue Jun 03 10:38:07 2025 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Tue Jun 03 10:40:04 2025 -0700 |
| tree | 17e644eb594a208824cc964e1b766db260caacf9 | |
| parent | c4e21ae9eadb2e0afa5a5007a87763c1d0fe5bbe [diff] |
[roll] Roll infra/recipes [fuchsia_roller] Remove backwards roll check commit 1fdf1df577ac9d565cd331b380e13d087bfa751a updated this recipe to use the `multi-repo-roll-resolver` tool to determine which commits to roll. This had the side effect that the recipe now ignores the Buildbucket triggering commit, and instead rolls all unrolled commits on the triggering branch of the repositories that it rolls. However, the builders that use this recipe still triggers on every commit, so we can run into a situation where: 1. Three commits land in a short window. 2. The builder triggers on the first of the three commits, but rolls all three commits. 3. The builder triggers on the middle commit, which hits the backwards roll detection because the triggering commit is different from the currently pinned version, but precedes it in the git history. 4. This triggers the backwards roll handling, causing the build to infra-fail, e.g. https://ci.chromium.org/b/8713115291013728353. The backwards roll check is really only necessary to prevent the recipe from actually rolling the repository backwards, but since we can tell that the commit has already been rolled, it's fine to just exit the same as we would if the triggering commit was equal to the current pinned revision. Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/infra/recipes/+/1291524 Original-Revision: aad58147911fb7725ec4fee82a5337c3d354440c GitOrigin-RevId: fd64e9bfe1bf72e36531d01fe510b635ddccc075 Change-Id: I6e9055066a4cf1a2c4cc35650323e9f638788e87
This repository contains Fuchsia's Global Integration manifest files.
All changes should be made to the internal version of this repository. Our infrastructure automatically updates this version when the internal one changes.
Currently all changes must be made by a Google employee. Non-Google employees wishing to make a change can ask for assistance in one of the communication channels documented at get involved.
First install Jiri.
Next run:
$ jiri init $ jiri import minimal https://fuchsia.googlesource.com/integration $ jiri update
Third party projects should have their own subdirectory in ./third_party.