When Jenkins jobs are started by a comment, and if the PR contains
`[skip ci]` in the description, Jenkins does not run the requested job,
nor set a status for the job in the PR.
This causes Mergify to add the `ok-to-test` label again, instructing a
GitHub Action to add comments to start jobs in Jenkins. Once all
comments have been posted, the `ok-to-test` label is removed. Mergify
then notices that the jobs were not run, and adds the `ok-to-test` label
again.... Endlessly looping of adding the label, commenting and removing
the label as a result.
By reporting the brokenness of the PR description and marking the PR as
Draft, the looping is prevented.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
k8s 1.30 tests were excluded for release-v3.11 but
merigfy had 1.30 tests conditions for release-v3.11.
This commit remove the these conditions for v3.11.
Signed-off-by: Praveen M <m.praveen@ibm.com>
When there is a conflict in merging a PR, the `ok-to-test` label should
not be added automatically. This prevents a loop in triggering CI jobs
for PRs that might not even build.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
auto merge for release-3.11 is already
convered with regex check and we cannot
auto merge PR to the devel branch.
Removing unwanted checks.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
we dont need a new mergify rule for
3.11 branch and the default mergirfy
with regex for `^(release-.+)$` branch
will cover it.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
this commit removes the automatic merge rule
for devel branch as this is always overwritten
from the conditions above and is not required
Signed-off-by: Yati Padia <ypadia@redhat.com>
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>
