Automate releases and standardize build step infrastructure

[choldgraf]

This repository recommends using GitHub releases to distribute the source code for plugins for others to re-use. E.g. see how we're using releases here:

myst-plugins/myst.yml

Lines 14 to 26 in a4df31e

	plugins:
	- https://github.com/jupyter-book/myst-plugins/releases/download/Admonitions/experiment-admonition.mjs
	- https://github.com/jupyter-book/myst-plugins/releases/download/exercise-and-solution-pdf/exercise-admonition-pdf.mjs
	- https://github.com/jupyter-book/myst-plugins/releases/download/Admonitions/intermezzo-admonition.mjs
	- https://github.com/jupyter-book/myst-plugins/releases/download/Admonitions/example-admonition.mjs
	- plugins/picsum/picsum.mjs
	- plugins/markup/markup.mjs
	# - plugins/iframe-to-thumbnail-pdf/iframe-to-thumbnail-pdf.mjs
	- https://github.com/jupyter-book/myst-plugins/releases/download/iframe-to-qr-pdf/iframe-to-qr-pdf.mjs
	- https://github.com/jupyter-book/myst-plugins/releases/download/updated-date-frontmatter/update-date-frontmatter.mjs
	- plugins/github-issue-link/src/index.mjs
	- plugins/github-handle-links/src/index.mjs
	- plugins/demo/src/index.mjs

But AFAICT, the releases are done manually, rather than through some kind of automation.

Additionally, some plugins require a 'build' step before they create a usable JS bundle, e.g.:

myst-plugins/plugins/update-date-frontmatter/build.js

Line 4 in a4df31e

We should:

1. Automate creating a release for any plugin that has changed since the last release.
2. Define a standard build step (maybe it is just "create a file called build.js and if it exists, the release workflow will run that and look for a file in a dist/ folder and publish whatever it finds there in a release for that plugin)

[FreekPols]

I have no experience in this, but what about this.

• Create a yml file to include all the plugins and their information (rather than in the readme).
• Load the data from that yml file into the readme (like in the JB gallery)
• If the plugin is set to stable, has an example, it will trigger a release.

Another thought, we now have a superlong url for the url, where ideally we only add the name of the plugin to our myst.yml file... can we do that?

[choldgraf]

That sounds like a good start - a quick question:

• how would a plugin "set to stable"?

Maybe each plugin could define the commit that it wants as stable using the yml file? And the build script would use that?

Maybe the repo could just publish them all nightly or something? Then if a plugin has enough complexity that it needs a proper versioning setup, we suggest it goes to its own repository?

For the URLs, I think that would require mystmd to give myst-plugind a privileged status to figure out the URL resolution. That feels like a bit much to do at this point, but maybe something we can work towards in the future if myst-plugins becomes heavily used and stable.

[FreekPols]

It is specified by the developer, where we have three levels: in development, tested, stable. The final one is where we expect that no further changes are needed or that whese will impact its behavior or requirements.

[choldgraf]

This makes me suspect we'd need to be more restrictive in scoping here. Maybe it is only for plugins with a tight scope that will get stability relatively early on? Eg that GitHub issue tables plugin does not fit this mold haha, it has been changing a lot.

[FreekPols]

Hasnt been set to stable, so no problem, right? My idea was to have a release of the version where the developers have the idea it is fine to go. I just used the release as it is the easiest way i could think of to embed it in a myst project. But that might be my limited knowledge!
Moreover, the structure might help to see what others are doing, to have it tested and get some feature request.

[FreekPols]

In this branch https://github.com/jupyter-book/myst-plugins/tree/yml_structure I created a .yml file from the plugin entries that are currently in the readme. I also created a .py file that converts the entries to a md table which is exported to .txt file in the _build folder and read in the plugin_overview.md file.
I don't know how to trigger the build of the .py file (though eager to learn): if I understand, the nox file can take care of that...

[choldgraf]

Yep you could run the .py file from within nox using a shell module/command if you want

[choldgraf]

I added a little bit of build standardization in #40 - we now have a nox -s build verb