```
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>
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>
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>
If a PR description includes `blocked by <pr>` or `depends on <pr>`,
this check will fail until the referred PRs are either merged or closed.
If this check is made required, it'll also block the merge button.
The details of the supported syntax can be checked at:
https://github.com/marketplace/actions/pr-dependency-check
Signed-off-by: Ernesto Puerta <epuertat@redhat.com>
This action automatically adds PRs with 'dashboard' label to the
'Dashboard' project (https://github.com/ceph/ceph/projects/6).
Signed-off-by: Ernesto Puerta <epuertat@redhat.com>
no need to have two actions triggered by the same event.
we could backport this labeler.yml to LTS branches.
Signed-off-by: Kefu Chai <kchai@redhat.com>
also use pull_request_target event so the action is run in the
context of the base of the pull request. this helps us to overcome
the "Resource not accessible by integration" issue where the action
is run in the context of the pull request.
Signed-off-by: Kefu Chai <kchai@redhat.com>
