Add GHAs to render/publish docs website

[andrewpbray]

Up till now I've been publishing the site locally using quarto publish netlify. I'm imagining two GHA:

1. On PR to dev or main, renders the branch and pushes it to closeread-pr.netlify.app. The main use of this is to have an automated check before merging. Hopefully all major features will be documented as Gallery > Demos as a source of tests.
2. On merge into main, rendersmainand pushes it to closeread.netlify.app. This is to keep the docs in sync with the version of the extension users will get when they runquarto add qmd-lab/closeread`.

[jimjam-slam]

This sounds good to me! Lmk if you need any help writing the actions!

[andrewpbray]

Currently futzing in https://github.com/qmd-lab/closeread/blob/main/.github/workflows/publish-pr-site.yml . This is recycling the image and action that I use for another big quarto project. I don't really remember how I set that one up, though, so I'm just kinda prodding in the dark here. Feel free to tinker and suggest other images if you've got a better tailored one!

[andrewpbray]

The current version seems to be running:

https://github.com/qmd-lab/closeread/actions/runs/11395061439

that publishes to closeread-pr.netlify.app. I'll change the on: so that it fulfills 1. above.

[jimjam-slam]

Here's an example of one of my actions creating a release using gh release create. That command has a --latest option for marking that release as the latest one, as well as -p flag for marking it as pre-release (not used in my example above but are documented).

[andrewpbray]

1. and 2. are now in place (I think..).

I should have set this up with an accompanying branch to make clear what was happening. For some reason, my brain thinks that GHA files are properties of github and not the repo itself, so I have a bad habit of editing them at github.com and committing directly to main 😬

[andrewpbray]

Oh, that publish release bit is great. I guess we can tack that onto the end of https://github.com/qmd-lab/closeread/blob/main/.github/workflows/publish-docs.yml ? (and probably want to rename to something like "document new release")

[jimjam-slam]

Haha, I tend to edit them in the browser too! It just means we need to merge the commit over to dev too, since actions need to be present on all branches involved in order to run (and I think on the default branch too, which wouldn't be a problem here).

Do we want on: push rather than on: pull_request for triggering builds? I think the latter runs by default as soon as a PR targeting dev or main is opened, which might not be what we want.

[andrewpbray]

I think for 1) I was thinking of using on: pull_request so that it can serve as a check that runs after every additional commit is added so that we know if we're in the clear before merging into dev (or main for that matter). For 2) I was thinking ofon: push, so that only after merging intomain` will we go ahead and publish the official closeread docs and make the release.

Does that make sense?

[andrewpbray]

Just to catch things up here, 1) and 2) were implemented and merged into dev in https://github.com/qmd-lab/closeread/pull/104 . I'm going to close this issue for now (knowing that we'll probably amend one of the actions in the future to make the release).