I noticed that there are a few commits on the main branch since the latest release. That got me thinking.
In GitGitGadget, I recently switched to an auto-releasing workflow. The idea is that whenever a push to main happens, the v1 branch is updated with a fake-merge commit that merges in main but whose tree reflects the compiled Action (and only that compiled Action, all source files are removed). That way, the Action's v1 branch always reflects the state of the main branch (modulo the short time window during which the updates happen).
Note: It is slightly more complex than what I just described, as the updates are skipped for updates to files like README.md that do not actually result in functional changes of the Action (this is done via a paths attribute).
We could establish the same here, with the v0 branch instead, and probably a simpler logic than what GitGitGadget requires.
@rimrul @mjcheetham what do you think?
I noticed that there are a few commits on the
mainbranch since the latest release. That got me thinking.In GitGitGadget, I recently switched to an auto-releasing workflow. The idea is that whenever a push to
mainhappens, thev1branch is updated with a fake-merge commit that merges inmainbut whose tree reflects the compiled Action (and only that compiled Action, all source files are removed). That way, the Action'sv1branch always reflects the state of themainbranch (modulo the short time window during which the updates happen).Note: It is slightly more complex than what I just described, as the updates are skipped for updates to files like
README.mdthat do not actually result in functional changes of the Action (this is done via apathsattribute).We could establish the same here, with the
v0branch instead, and probably a simpler logic than what GitGitGadget requires.@rimrul @mjcheetham what do you think?