publish through GH releases

[parmentelat]

this is a follow-up on jupyter-book/mystmd#2317

in this first step, we add a GH workflow that publishes both book and article themes as GH releases attached to the current repo

this clearly is only a first step, but I would argue it should be merged right away

in particular this means a regular fork can use the same mechanism to publish its custom version by just setting a tag

see the issue for a status of the overall migration path

[changeset-bot]

⚠️ No Changeset found

Latest commit: 309177f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[netlify]

❌ Deploy Preview for myst-theme failed. Why did it fail? →

Name	Link
🔨 Latest commit	309177f
🔍 Latest deploy log	https://app.netlify.com/projects/myst-theme/deploys/6909c54591d2de0008a5c7af

[agoose77]

Thanks for this PR! I tend to prefer release-driven workflows in contexts like this. Have you thought about using a release to trigger the CI? I think this would simplify various parts of the workflow.

[parmentelat]

As it is now, pushing a tag on github will trigger a release named after the tag
Let me know if that requires more work

[parmentelat]

Hi
would you care to elaborate what exactly you meant with

Have you thought about using a release to trigger the CI?

one of the avenues I did give some thought to was the ability for mystmd releases to refer to a pinned version of the theme it relies upon
the current situation, where it's the latest release that gets pulled at run-time, and then cached, seems quite fragile on the long run; I have already personally experienced this drawback a couple months back, and things can only get uglier over time, imho :)
this current move was a first step towards reaching the point where pinning would become possible, at least that was the intention

another, more immediate rationale, was to make it easier for forked themes to produce their own releases; that's the workflow I am currently using to run on our own tweaked theme
https://github.com/flotpython/myst-theme/
that for now just adds a 'fullscreen' button close to the dark/light button, as you can see e.g. here
https://numerique.info-mines.paris/

[stevejpurves]

Hi @parmentelat,

Thanks for the PR and it's great to have the longer thread linked for context!

I had some questions/comments:

• Is the intent for this action to only publish the book and article themes or to also bump and publish all the dependent packages at the same time via changesets? (in which case we'd need to bring run version and publish too.)
• Were you aware of the existing build-theme step in the Makefile, or was there a reason you did not opt to call that - using the existing packaging mechansim would mean one source of truth for building the zip
• Should this not also run make deploy-theme so that the theme bundles on myst-templates are updated at the same time? and gh release version and the published templates are in sync at least wile that is the primary method for the myst CLI to download them?