feature: automate tagging an releasing

[j-i-l]

Closes #25

Closes #12

Closes #8

Closes #77

Closes #79

Closes #83

Closes #26

---

We need the following workflows:

• initiate a new release branch CRAN and general release preparation #79
  • run when main is tagged with x.x.x-rc Tag based deployment pipeline including fast/slow checks #25
  • Update the NEWS.md file
  • Update the DESCRIPTION file
  • update configure.ac file
  • run pkgsdown rendering
  • run R CMD check as for CRAN
  • check URLs/spellchecker/linter
• run when pr is labeled with memory::check label (comes with 26 tests tracking memory usage the slow pipeline #89 Tests tracking memory usage (the slow pipeline) #26)
• run when pr is labeled with pckgdown::check to render pckgdown
• run on every push to a non-release- branch (also excluding main)
  • correct conditions to run
  • get the changed files in the pr
  • perform testthat targeted to changed directories/files
• run when pr for release- branch is merged
  • only publish if the pr has no label release::published
  • create a clean tag Streamline versioning process #12
  • publish a release of this tag on gh Tag based deployment pipeline including fast/slow checks #25
  • [ ] build vignettes implement automatic recompilation of the vignettes #50
  • publish pgkdown content
  • mark the pull request as release::published (label)
  • adding .tar.gz of package to release package archive as artifact #8
• run when a clean tag is put on a commit in a release- branch (e.g. in case of a merge conflict) Streamline versioning process #12
  • publish a release of this tag on gh Tag based deployment pipeline including fast/slow checks #25
  • [ ] build vignettes implement automatic recompilation of the vignettes #50
  • publish pgkdown content
  • mark the pull request as release::published (label)
  • adding .tar.gz of package to release package archive as artifact #8

[j-i-l]

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

[j-i-l]

up next let's consolidate the actions pipelines.

[matteodelucchi]

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

[j-i-l]

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).

[j-i-l]

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

[j-i-l]

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)

[matteodelucchi]

[j-i-l]

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

[matteodelucchi]

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

[j-i-l]

targeted testing seems to work

[j-i-l]

ok, targeted testing works as expected!

[j-i-l]

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

[j-i-l]

@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. 👍