non-SLURP branches are EOL'd in case they reach their end of maintained
phase. This could produce a situation when a patch is merged in a
non-SLURP branch that was deleted in the meantime and it's further
backports fail on gate with backport validator as the hash of the
non-SLURP version of the patch is not on any branch.
This patch fixes the above issue as follows: in case a hash is not
found on any branch, then it checks if it can be found under any *-eol
tag and only fails if there is not found either.
Change-Id: I56705bce8ee4354cd5cb1577a520c2d1c525f57b
When the script was created there were only stable/* branches, but now
there are unmaintained/* branches as well, where the validator fails
when looking for hashes only on stable/* branches even if the given
hash is already on unmtaintained/* branch. This patch matches now both
stable/* and unmaintained/* branches.
Change-Id: I08fcc63ab0fbe5af1be70d5fde5af98bf006101c
This is a fix for the test whether a patch is bot generated or not, as
that did not worked as intended. The problem is that the script is
checking the email address of the parent patch (HEAD~), which probably
should be right in case the patch would be a MERGE patch. But this is
wrong in case the patch is not a MERGE patch. This fix uses the very
same pattern as it is using for the commit message parsing: the
$commit_hash variable, which is the parent's commit hash if the patch
is a MERGE patch, and an empty string in the other case (causing to
call 'git show' on HEAD).
Change-Id: I0abc72180edf34a6dd0624a40fb8682397805eca
validate-backport job started to fail as only old stable branch naming
is accepted. This patch extends the script to allow numbers and dot as
well in the branch names (like stable/2023.1).
Change-Id: Icbdcd5d124717e195d55d9e42530611ed812fadd
Don't force infra to change their bot because of our weird script. If
it's from the OpenStack Release Bot, it's probably good and we can skip
the backport check.
Change-Id: I682bd198a74fc252e47e8bdfb33bd21782b63ff9
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This currently runs in the 'check' pipeline, as part of the pep8 job,
which causes otherwise perfectly valid backports to report as failing
CI. There's no reason a stable core shouldn't be encouraged to review
these patches: we simply want to prevent them *merging* before their
parent(s). Resolve this conflict by moving the check to separate voting
job in the 'gate' pipeline as well as a non-voting job in the 'check'
pipeline to catch more obvious issues.
Change-Id: Id3e4452883f6a3cf44ff58b39ded82e882e28c23
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The checks performed by this script aren't always useful to downstream
consumers of the repo so allow them to disable the script without having
to make changes to tox.ini.
Change-Id: I4f551dc4b57905cab8aa005c5680223ad1b57639
This is a follow up to change
I8e4e5afc773d53dee9c1c24951bb07a45ddc2f1a which fixed an issue with
validation when the topmost patch after a Zuul rebase is a merge
patch.
We need to also use the $commit_hash variable for the check for
stable-only patches, else it will incorrectly fail because it is
checking the merge patch's commit message.
Change-Id: Ia725346b65dd5e2f16aa049c74b45d99e22b3524
Cherry-pick check script validates the proposed patch's commit message.
If a patch is not on top of the given branch then Zuul rebases it to
the top and the patch becomes a merge patch. In this case the script
validates the merge patch's commit message instead of the original
patch's commit message and fails.
This fix selects the parent of the patch if it is a merge patch.
Change-Id: I8e4e5afc773d53dee9c1c24951bb07a45ddc2f1a
This adds a tools/ script that checks any cherry-picked hashes
on the current commit (or a provided commit) to make sure that
all the hashes exist on at least master or stable/.* branches.
This should help avoid accidentally merging stable backports
where one of the hashes along the line has changed due to conflicts.
Change-Id: I4afaa0808b75cc31a8dd14663912c162281a1a42
Elod Illes