Currently push to publish branch happens after online-sign, to mean "this looks ready for the publish-test-prodpublish cycle".
- this is not 100% accurate since the tests can of course fail: at this point publish branch is a) published to first stage but b) cannot be published to prod as is
- original reason for "publish" was that it would be easy for the publishing workflow to figure out which commit to publish... but because GitHubs git consistency was not great, we ended up adding a
ref argument to the workflow anyway so it's a bit pointless
- in addition, GitHub settings have recently changed so that you cannot enable Pages for a branch that does not yet exist, making our setup documentation impossible to strictly follow
I think we should bite the bullet and simplify this:
- online-sign should not push to publish branch
- publish workflow should just run on main (it gets a
ref input anyway)
- Maybe publish branch still makes sense (to document what has been published) but it's not clear how this relates to e.g. root-signing setup with a staging and production publish....
I'm not sure what the migration looks like for existing installations: I think it's just about switching the Pages branch from publish to main when the actions are upgraded.
Currently push to publish branch happens after online-sign, to mean "this looks ready for the publish-test-prodpublish cycle".
refargument to the workflow anyway so it's a bit pointlessI think we should bite the bullet and simplify this:
refinput anyway)I'm not sure what the migration looks like for existing installations: I think it's just about switching the Pages branch from publish to main when the actions are upgraded.