The `queue_rules` were updated earlier, but the rule for moving a
backport PR to the queue was not. By splitting the conditions for
release-v3.9 and other (newer) releases, the PRs can be queued with
their required Kubernetes version tests.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
It seems that `base=release-v*` does not match the `release-v3.10`
branch for some reason. Maybe a Mergify update requires stricter
checking of strings, and only allows the `~=` operator for regular
expressions now?
Regular expressions like `base~=^(devel)|(release-.+)$` seem to match
for `release-3.10`, so let's use that notation everywhere.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
The new `allow_merging_configuration_change` option can be enabled to
> Allow merging Mergify configuration change.
Which is useful for a more automated process when preparing for a
release.
See-also: https://docs.mergify.com/workflow/actions/merge/#parameters
Signed-off-by: Niels de Vos <ndevos@ibm.com>
K8s 1.24 will be End of Life on 2023-07-28.
Therefore, removing checks for ci tests on
that version.
refer:
https://kubernetes.io/releases/#release-v1-24
Signed-off-by: Rakshith R <rar@redhat.com>
Author of mergifyio created pr is mergify[bot].
It needs the suffix `[bot]` for the condition
to be evaluated to true.
Signed-off-by: Rakshith R <rar@redhat.com>
It seems that some PRs still get rebased by Mergify, whereas others get
tested for the **merge queue** by creating a new temporary PR. In both
cases the `ok-to-test` label should get set automatically.
Fixes: c4d372e (ci: automatically add `ok-to-test` to PRs created by Mergify)
Signed-off-by: Niels de Vos <ndevos@ibm.com>
Mergify does not automatically rebase PRs that are queued for merging
(anymore?). Instead, it creates a new draft PR that is expected to get
tested by the CI. At the moment someone needs to add the `ok-to-test`
label to the PR. This is cumbersome and can cause delays in the merge
process.
The configuration for Mergify now includes a rule that any PR created by
Mergify, will automatically get the `ok-to-test` label. This should make
it easier to get PR merged.
See-also: #3796
Signed-off-by: Niels de Vos <ndevos@ibm.com>
Mergify does not add the `ok-to-test` label immediately anymore. But
once the CentOS CI jobs have finished, the label still gets added. With
the additional check, this should not be the case anymore.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
After the `ok-to-test` label was added, the commenter will remove the
label again. There is no need for Mergify to re-add the label while CI
jobs are still running.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Sometimes Mergify removed the `ok-to-test` label before the Pull Request
Commentor action have been run. With the updated commentor action, the
`ok-to-test` label is removed after leaving comments. There is no need
for Mergify to remove the label anymore.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The check for a rebase always hits, but the actions for that inspect the
event for a real rebase. Removing the `ok-to-test` label is not suitable
in the Mergify check, as the label action does not inspect the event.
This caused the `ok-to-test` label to be removed on every Mergify
validation of the PR.
Fixes: ba68ce6 (ci: drop `ok-to-test` label when a PR is rebased)
Signed-off-by: Niels de Vos <ndevos@redhat.com>
`bot_account` is a feature that is part of the paid subscription. The
Ceph organization does not have that.
Mergify will use the author of the PR for rebasing by default. This
isn't very nice, but we can't change it at the moment.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The `bot_account` option was not part of the Open Source plan, but now
it is. When Mergify rebases PRs, it sometimes leaves the following
message:
```
This pull request got rebased on behalf of a random user of the
organization. This behavior will change on the 1st February 2023,
Mergify will pick the author of the pull request instead.
To get the future behavior now, you can configure bot_account options
(e.g.: bot_account: { author } or update_bot_account: { author }.
Or you can create a dedicated github account for squash and rebase
operations, and use it in different bot_account options.
```
It is clearer for everyone when the Ceph-CSI Bot is used for automated
actions. Contributers might get confused why the PR was updated in their
name, without them doing anything.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
It seems that Mergify removes the `ok-to-test` label as soon as someone
adds it. We don't want that, as it can trigger more CI runs than needed.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The `ok-to-test` label currently needs to be removed and re-added when a
PR is rebased for re-queuing.
It should be possible to automate this, by removing the `ok-to-test`
label when a PR gets queued. It can automatically be added again when
the PR has embarked the merge train.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
As we have successful runs with kubernetes
1.25 Marking is as default for CI jobs and
required for merging PR.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
As we need to test with last 3 Kubernetes
releases removing Kubernetes 1.22
as we have 1.23, 1.24 and 1.25
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
considering we have 3.7 release in place, this commit remove
the release 3.5 backporting based on the labels in the repo.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
Comment out `comment: ` settings, since it
does not have any options set, otherwise
throws the following error.
```
The current Mergify configuration is invalid
required key not provided @ defaults → actions → comment → message
```
Signed-off-by: Rakshith R <rar@redhat.com>
Updating mergify rules to consider CI run on
Kubernetes 1.24 and discard CI run on kubernetes
1.21 as we no longer need it.
updates: #3086
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
we already have generic rules to merge the PR's
in devel and release branches with `automatic merge`
rules. Removing the duplicate release-3.5 rule.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
"component/nfs" has been added to the labels in the repository, and
Mergify should be able to add that to PRs.
Updates: #2913
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Pull requests are not going to be queued if at the same time the pull
request review are dismiss
Original-author: Mehdi ABAAKOUK <sileht@sileht.net>
Signed-off-by: Niels de Vos <ndevos@redhat.com>
By the addition of the queue rules in the Mrgify configuration, all PRs
that require changes, or have been updated and review should be dropped,
are now added to the queue for merging. This is obviously not what we
want.
Fixes: 43fc945 ("ci: move from merge action to queue action")
Signed-off-by: Niels de Vos <ndevos@redhat.com>
as mentioned in the below blog the support for strict mode
and merge action will be done soon in mergify. This brings
the change requested for the same.
Ref# https://blog.mergify.com/strict-mode-deprecation/
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
as we added kubernetes 1.23 for mergify, removing
older version i.e 1.20 as we will run tests
only on latest 3 kubernetes releases.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
as we are running tests on kubernetes 1.23 by
default, adding mergify condition to check test
passed on kubernetes 1.23 also.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
It seems that the matching condition on the modified files with
-files~=^(!?actions/)
validates to 'true' when that is not intended. The example in the
Mergify documentation does not seem to be correct :-/
This reverts commit 411bf33a3d.
See-also: https://docs.mergify.com/examples/#merging-based-on-modified-files
Signed-off-by: Niels de Vos <ndevos@redhat.com>
PRs that contain `mergify` or `Mergify` in the subject should both match
the rule to add labels. The regular expressions can include `(?i)` to
make the matching case-insensitive.
See-also: https://docs.mergify.com/configuration/#regular-expressions
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The matching checks the list of modified files, and if it does not
contain anything outside the `actions/` directory, the labels are
applied.
Actions are not tested with e2e, so changes can be labelled to skip
these time and resource intensive tests.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
