publish_release.yml runs as expected.
Now we should only trigger it on commits to main and if CRAN-like action succeeds.

up next let's consolidate the actions pipelines.

The checks in #85 fail because of an issue with pulling the containers (see here). Is this related to this PR?

The checks in #85 fail because of an issue with pulling the containers (see here). Is this related to this PR?

Nope, this was related to my doings around furrer-lab/r-containers#28. I had accidentally deleted the latest-tagged containers, thus requesting them would lead to a failure in the container initialization.

In #85 now the url check leads to a failure of the quick tests pipeline. Including changes from main will update the testing setup (url check moved to CRAN-like checks and is allowed to fail, since it has issues on its own).

I see the following requirements for our version release pipeline:

1. Adhere to versioning standards - semver in this case
2. Use git tags as single source of
   truth for the versioning
3. Allow to include information about the version in the code-base itself
4. Allow to run and address resulting issues of designated pre-release tests (and potentially other worklfows)
5. Include the released state of the repository in the reference branch

I went ahead and set up a toy repository that implements a half-way (actually mostly) automated pipeline that allows to address these requirements:

https://github.com/t4d-gmbh/stubbed_versioning

Allow to add artifacts when running the release- branch actions > generate .tar.gz for CRAN

Delete the release-.. branch after merge (recreate it from the cleaned tag if needed)

With #87 (addressing #26) we will have all the steps ready. I'll start to distribute them afterwards.

On development branch, run tests conditionally on where changes were done. See #83.

targeted testing seems to work

ok, targeted testing works as expected!

Now only #50 remains. I'm going to move this out of the pr and resolve it as some later point.

@matteodelucchi There is now a protection rule for pr, they require the job R_CMD_check_passed to succeed. This pr should (in a few hours) have this check ready.

Then the pr should be ready to be merged, just go ahead an merge it.

Then you can push a tag 3.0.8-rc2 to the main branch. After a while a new pull request should pop-up that wants to merge the branch release-3.0.8 into main. Also there will be a few tests that start running. You might want to adapt the NEWS.md file that was changed automatically.

If you then merge this newly created pull request back to main, we have our version ready for submission. 👍