Workflow to automatically create a GitHub issue with a template
listing required API updates is in place for a while. Let's remove
the corresponding TODO from the file.
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
By placing actions/checkout before actions/setup-go[1] we could avoid
the following warning message:
Warning: Restore cache failed: Dependencies file is not found in
/home/runner/work/go-ceph/go-ceph. Supported file pattern: go.sum
[1] https://github.com/actions/setup-go/issues/281
Signed-off-by: Anoop C S <anoopcs@cryptolab.net>
Enable stale bot to mark PRs stale and eventually close stale PRs. I had
tried to manually do this in the past with nice comments but I forget
to do it and trying to be nice was unrewarding. I find a bunch of old
PRs in the list a distraction and don't want to have to think about them
or try to follow up on them. I want to be generous to PR authors so PRs
can be inactive for 60 days and one has 3 weeks to unstale the PR.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
After adding the reef job, it was noticed that there was no quincy job.
Apparently we (probably me) forgot to add it at the time we added quincy
to our CI matrix, so we're adding it now.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
As reef is being added and there's very little activity going into
pacific now, it should be safe to stop testing pre-pacific.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This bumps the Go version of the test container to 1.19.5, which is
the oldest supported Go version as of now.
The go.mod file (including an upgrade of its dependencies) and the
revive environment is bumped to 1.19 as well.
Signed-off-by: Sven Anderson <sven@redhat.com>
As noted in the status on github:
```
The configuration uses the deprecated rebase_fallback attribute of the
queue action.
A brownout is planned on February 13th, 2023.
This option will be removed on March 13th, 2023.
For more information: https://docs.mergify.com/actions/queue/
```
Therefore we'll simply drop this attribute.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
The linebreaks within the 2 bottom paragraphs look fine in an editor
such as vim, but look odd when viewed as part of the PR on github.
Improve the visuals and make it more readable in the github UI by
removing linebreaks.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Add a new checklist item reminding contributors to run `make
api-update` to track new APIs. Add two short paragraphs that
cover some of the common things I copy and paste or need to look up
when working with contributors' PRs.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This is a manual workflow, you must trigger it from the github ui,
but most everything after that is automated.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Turns out the dependabot tool can also indicate what github actions we
are using can be updated. This can be handy in avoiding the warnings
that github throws up all over an action that relies on a deprecated
feature. Use a monthly update just like go modules to avoid being
pestered all the time.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Right now this workflow needs to be run manually and it will generate
some files that are archived. The plan is to build upon this as a base
eventually teaching the workflow how to automatically file an issue
reporting on what API updates are needed after each release.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
When archiving, use the latest version of the archive action and use
it's ability to archive an entire directory.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Lower the frequency of updates. The monthly update is documented to
occur on the first of the month, which works better with our
every-other-month release cadence.
Automatically apply the "no-API" label. Do not add a rebase label, which
has not relevance to the go-ceph workflow.
Use the prefix "go-ceph:" which is what we normally use for changes only
to the go.mode, etc.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
We will (most probably) remove non-ptrguard code before the next
release. Let's skip the tests already now, because they double the
likelihood of failing flaky tests.
Signed-off-by: Sven Anderson <sven@redhat.com>
Dependabot can automatically create PRs for packages that have have a
new release. By depending on recent versions of the consumed packages,
the result of the OpenSSF scorecard will improve.
See-also: https://deps.dev/go/github.com%2Fceph%2Fgo-ceph/
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Mergify has not been working for weeks as they removed support for the
deprecated style we were relying on. This is my first attempt to
update it to the new style.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
It's too easy to forget to triage a PR with the API label, and then
if the PR looks good and is approved the mergify system will merge
it. Move to using an explicit "no-API" label for marking the PR as truly
not having API changes and not requiring a 2nd review.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
The new make targets allow us to share (mirror-enabled) ceph container
instances. Use this to test both non-ptrguard and prtguard test runs
while dropping the (now redundant) non-mirror-enabled ceph + tests
container run.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
This implements the policy first outlined in
https://github.com/ceph/go-ceph/discussions/549
In short: if a PR includes API changes (has the API label) then
either 2 reviews are required or 1 review plus 10 days must pass;
if a PR includes no API changes, then only 1 review is needed.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Tests are running against Ceph Pacific and passing, so this can be
marked as a required CI status.
dpulls handles dependencies between PRs, once the status is marked with
success, the requirements have all been merged. Prevent merging when
dpulls is in a failed state.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
In order to run CI jobs also on PRs that are based on other PRs, this
change adds the pattern 'pr/**' to the tested base branches. That
means, if PRs are pushed that are based on branches that start with
pr/... these PRs are also get tested. So, if we - by convention - push
PRs to branches like for example pr/ansiwen/myfix42, then all PRs
that are not based on master but another PR get tested as well.
Signed-off-by: Sven Anderson <sven@redhat.com>
The "extended-review" label indicates that review is likely to take
an extended period of time and for bots to not automatically take
a PR.
This avoid the need to preemptively mark a PR as changes needed or
give a false impression with a "do-not-merge" tag, which has a subtle
lack-of-quality implication.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Anoop C S
dependabot[bot]
Sven Anderson
John Mulligan
Niels de Vos