```
Error: Request failed due to following response errors:
- Could not resolve to a ProjectV2 with the number 2.
```
On further investigation, it looks like it could be a permission issue.
I followed the recommendation in their documentation to fix it: https://github.com/actions/add-to-project#creating-a-pat-and-adding-it-to-your-repository
Signed-off-by: Nizamudeen A <nia@redhat.com>
Assume ownership of qa/workunits/windows. Despite the generic name,
currently it has just rbd-wnbd tests.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This happens because core and rbd ownership is defined after
doc-writers: a later match takes precedence.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
In response to https://tracker.ceph.com/issues/58173, it would have helped to have the PR label librados test files with core, so the PR would have been tagged for rados qa.
Signed-off-by: Laura Flores <lflores@redhat.com>
Currently, the stale bot closes PRs 90 days after they are marked stale since it counts "marking a PR stale" as activity.
We really want the PRs to close after a total of 90 days, or 30 days after they are marked stale. Changing `days-before-prs-close` to 30 will fix this.
Signed-off-by: Laura Flores <lflores@redhat.com>
The old (classic) Dashboard project (https://github.com/ceph/ceph/projects/6) has been migrated to a new-style one (https://github.com/orgs/ceph/projects/2/views/1).
This also requires updating the GH Action that automatically assigned `dashboard`-labeled PRs to the Dashboard project.
Signed-off-by: Ernesto Puerta <37327689+epuertat@users.noreply.github.com>
Otherwise GitHub sends an annoying e-mail right away when you file a PR that doesn't have the checklist filled out. It's easier IMO to create the PR, then check the boxes instead of putting Xes in brackets while filling out the PR comment.
Signed-off-by: David Galloway <dgallowa@redhat.com>
Currently there's a cron job in a teuthology VM running a script to find all trackers in needs-backports and to create their corresponding backport trackers. This is done through the [Backport Bot](https://tracker.ceph.com/users/12172) Redmine account.
This PR intends to run this cron job task as a periodic Github Action.
Signed-off-by: Ernesto Puerta <37327689+epuertat@users.noreply.github.com>
Signed-off-by: Ernesto Puerta <epuertat@redhat.com>
The stale bot's `operations-per-run`
(https://github.com/actions/stale#operations-per-run) corresponds to the max
number of API calls it is allowed to make per hour. Currently,
`operations-per-run` is set to 30, which means that the stale bot
can make up to 30 API calls per hour.
With this limit in place, the stale bot is only able to process 400 PRs at a time.
Since there are 900+ PRs in the Ceph repository, we should increase the number of
operations to cover them all. This needs to be done with care though, since GitHub
has a rate limit
(https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting)
depending on business plan.
According to GitHub's documentation on GitHub action requests
(https://docs.github.com/en/rest/overview/resources-in-the-rest-api#requests-from-github-actions),
the rate limit is 1,000 requests per hour per repository when using `GITHUB_TOKEN` (which we are).
For enterprise accounts, GitHub Enterprise Cloud's rate limit applies, and the limit is 15,000
requests per hour per repository.
Based on this information, we should be fine to increase the max `operations-per-run`
to 100. This would cover a little over 1000 PRs, which should be enough
to process the 900-some-odd PRs in the Ceph repository.
Signed-off-by: Laura Flores <lflores@redhat.com>
Currently, the stale bot runs once a day at 1:30 UTC.
This will only process a few PRs per day, which is not
enough to handle the volume of PRs that come into the
Ceph repository. Running the bot once every hour with
a limit of 30 operations will keep within the rate
limit, but it will also process more PRs per day.
Followup to 1a8d201037.
Signed-off-by: Laura Flores <lflores@redhat.com>
The Ceph repo has many PRs and we cannot process all the PRs with the
default "operations-per-run" value (30). At the time of writting the bot
processes 408 every day and there are around 938 PRs.
Even the job informs us that not enough PRs might have been processed
and encouraged us to increase "operations-per-run" if possible. However
it might expose us to Github's API rate limit.
So let's operate with the oldest PRs first, this should close a bunch of
PRs already. If not enough we can try to increase "operations-per-run".
Signed-off-by: Sébastien Han <seb@redhat.com>
I think https://github.com/tibdex/backport will only create backport PRs if our doc/releases PRs are labelled *and then* closed. This action currently labels after the PR is closed.
Signed-off-by: David Galloway <dgallowa@redhat.com>
e.g., add a 'backport quincy' label to a PR and this workflow will automatically create a backport PR
Signed-off-by: David Galloway <dgallowa@redhat.com>
codeowners: remove api team
Reviewed-by: Sarthak Gupta <sarthak.dev.0702@gmail.com>
Reviewed-by: nSedrickm <NOT@FOUND>
Reviewed-by: Nizamudeen A <nia@redhat.com>
These guidelines refer contributors to the "Submitting Patches to Ceph" doc
and the "Submitting Patches to Ceph - Backports" doc. Even though there are
already tips for titling/signing commits in the PR template, these tips
are commented out and easy to gloss over once the contributor creates the
PR. These existing tips do not include any pointers about staging backports.
Fixes: https://tracker.ceph.com/issues/55418
Signed-off-by: Laura Flores <lflores@redhat.com>
In `master` the milestone step exits and causes remaining tasks not to be run. I previously tried with the `continue-on-error` flag, but it didn't work, so let's try putting that steps at the end.
Signed-off-by: Ernesto Puerta <epuertat@redhat.com>