Skip to content

Rethink "publish" branch usage #487

@jku

Description

@jku

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions