Reusable automated release machinery

[vados-cosmonic]

We've recently added machinery to both jco and componentize-js that enables automated releases. It would be great to have the actions that power that functionality hosted here to make them easier to reuse on different projects.

The actions favor a mono-repo approach, but work decently well for single projects as well, as long as the project owner is fine with tags like<project>-v<version> rather than just v<version> (i.e. a single-project repo named example would have tags for releases named example-vX.X.X instead of the simpler/implicit vX.X.X).

See:

• https://github.com/bytecodealliance/jco/blob/main/.github/workflows/create-release-pr.yml
• https://github.com/bytecodealliance/jco/blob/main/.github/workflows/release.yml
• https://github.com/bytecodealliance/jco/blob/main/.github/workflows/tag-release.yml
• componentize-js integration (somewhat specialized for single project)

[ricochet]

We have a monorepo here to make maintaining our actions easy, however any action that we want hosted within the github marketplace must be in it's own repo (GH limitation) and submoduled here. Are the actions that you created generally useful outside jco and componentize-js?

[rajatjindal]

Hi @vados-cosmonic, apologies for missing this ticket earlier.

I think this repo is not a good place to host "reusable actions to release projects". In my mind this repo is for "reusable actions for setup/use of bytecodealliance projects".

maybe we can have a "release-actions" repo to host the reusable workflows?

[vados-cosmonic]

Hey @ricochet , @rajatjindal

Thanks for the feedback here -- to address @ricochet 's concern, the actions are generally useful outside (they work for Rust and JS projects), but they are specific in that they are for releasing projects.

This brings up a good point -- the actions don't really need to go on the marketplace, they're more for use by BA projects.

As for @rajatjindal 's concern, I see -- if this repo is more for "external"/"user facing" actions, then that totally makes sense. The idea that we should create a repo for "internal"/"developer facing" is a good one, I'm certainly happy to add changes there!

Are we agreed on creating a new repo instead? The name release-actions works for me but maybe something more general is good like actions-internal or project-actions, since there could be actions in there which are useful but aren't necessary release-related (and making <x>-actions repositories repeatedly sound a bit painful)

[rajatjindal]

Are we agreed on creating a new repo instead? The name release-actions works for me but maybe something more general is good like actions-internal or project-actions, since there could be actions in there which are useful but aren't necessary release-related (and making -actions repositories repeatedly sound a bit painful)

This sounds good to me, but would be good to hear feedback from @ricochet as well. thank you 👍.

[ricochet]

This sounds good to me. On behalf of operationalizing the hosted projects that you maintain @vados-cosmonic, I created https://github.com/bytecodealliance/project-actions. It is set this to internal while you bootstrap the repo. Thanks!