Local release workflow

[tingerrr]

Currently, the release workflow is used to publish the package to typst/packages.

I propose changing it to be named publish and add a new workflow called release which actually handles the release on the repo itself.

This new workflow should either:

• on push of a tag matching v*: create a new draft release, or
• on creation of a release, upload release artifacts to a release page.

In either case, such an action should do a few things:

• Generate a default changelog from either a CHANGELOG.md file or the main git commit history
  • Although GitHub can do the latter for you, so this might not be too important.
• Compile and package supplementary material for a release, like manuals and other assets.
  • There's no hard rule on how documentation is done for Typst packages yet, most people simply compile a manual, some others like cetz host their own GitHub Pages, we could look at popular packages and adapt some of their practices.

[jamesrswift]

I agree that splitting publishing and releasing into separate commands would be beneficial - too many times have I botched a release and needed to manually clean up branches and tags, when it could have been averted by splitting the process

[SillyFreak]

I am working on this now, here's the begin of an attempt: https://github.com/SillyFreak/typst-package-template-playground

Right now, pushing a v* tag triggers creating a draft release and adding a zip file to that release. The zip file contains everything that until now has been included in the pull request.

What I'm wondering now is:

• how to best trigger the pull request? By publishing the release? If so, it seems cleaner to take the already created release artifact instead of packaging anew, but I'll have to figure out if that's possible cleanly
• should there be a second artifact that doesn't contain excluded files? I.e., should we try to create archives that mirror what can be downloaded from Universe, such as https://packages.typst.org/preview/cetz-0.4.0.tar.gz?

I didn't bother with a changelog for now. We could try to extract something from CHANGELOG.md but honestly I'm reluctant to put too much new logic into the CI; I want to get rid of the current scripts in favor of e.g. typship this summer, and not add too much new shell scripting...

Am I missing any other requirements you or people might have?

[tingerrr]

Considering that this works well so far and that you plan to contribute parts of this to typship anyway, perhaps this it's best to jump straight to that right away?

EDIT: Since workflows can be triggered manually, you could perhaps check for the latest release on a manually triggered publish workflow and use the artifacts for the PR.

[SillyFreak]

perhaps this it's best to jump straight to that right away?

do you mean trying to integrate typship before tackling this issue, or specifically the changelog thing?

My though was, by tackling this first I would get a better idea on what the template's requirements from typship will be. So that I don't make demands of typship that ultimately end up unused. Simply ignoring the changelog for now (it's not a regression) and looking at it after typship is integrated sounds good though.

you could perhaps check for the latest release on a manually triggered publish workflow and use the artifacts for the PR

that sounds good!

[tingerrr]

I was thinking the whole thing, but it makes more sense to first try it out here and see what can be ported to the tool.