ci: split PR build and release build to manually trigger builds of artifacts

[simonsan]

This changes the CI release workflow to be split into release builds of release/ and main branch and PR builds (which are triggered manually) for PRs with the label S-build.

I think this is beneficial, because we run the full build pipeline for each commit, which is a waste of resources. When we can just trigger it manually once we think a PR is in a state we want to create artifacts (e.g. for testing)

The flow is as follows:

1. run checks, tests, security audit, and lints automatically
2. wait for label S-build
3. set label S-build
4. build artifacts and push them to actions artifact storage
5. remove label S-build (for retriggering the build workflow)

This needs to be merged after #843 as the release workflow needs to be changed WRT to uploading binaries which was not working before.

[simonsan]

Need to get the permissions right, probably.

Resources

• "Resource not accessible by integration" actions/first-interaction#10
• https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
• https://docs.github.com/en/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests

[simonsan]

The problem could lay somewhere else, the reason for it not working could be that from a PR we don't have access to the owned repository. It might just magically work, when it is merged.

If that's still not the case, the last approach would be, to use something like C-bug, C-enhancement and other labels as triggers, where we would like to have artifacts. In the majority of cases, though, I would say, that we don't need artifacts of rustic and probably rather build it ourselves locally.

So all the lints, tests, checks, and audits should be giving us a good overview, whether we will run a full cross-platform build or not. With improving the test coverage, running tests should be more meaningful anyway. There are some platforms, where at least one build before merging is beneficial, this use case we already have with setting S-build manually.

Currently, we would need to remove and re-set the S-build flag manually, if we want more cross-platform build. I do believe that this should solve itself after merging, though.

[simonsan]

gh api --method DELETE -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" /repos/rustic-rs/rustic/issues/838/labels/S-build i tested the API call manually, and it works, I assume it will also work from the main branch when it's within the repository.

[simonsan]

Also, this: Could you give it a rough look, @aawsome because I'm unsure if the direction is fine? Thanks a lot!

Personally, I think it would help a lot to have only the basic checks running, and the platform builds only when we explicitly ask for them.

[simonsan]

We have a few possibilities with the nightly builds on https://github.com/rustic-rs/nightly now:

• we could get rid of the release workflow from main completely for now and create one to have a release PR to make it easier to release more often
• we could edit this workflow here and make it listen to workflow_dispatch so we can trigger it in the actions tab if we need to
• or we could merge this here, I'm pretty positive that it would work like that, and if not we can still go down the route with the workflow_dispatch