Separate publish from snapshot.

[kommendorkapten]

Today the publish (deploy) happens as a step in either the snapshot or online version bump workflow. Preferably is to have deployment as a single workflow that other workflows can call into. This would also make it easier in the future to force a deployment to recover from a situation where the deployment fails.

One example today: if the snapshot job runs (and successfully updates the main branch), but deployment fails, following snapshot jobs does not publish as the snapshot did not update anything -- main branch is in a good state.

[jku]

As detail from #125:

• snapshot and online-version-bump should not decide or take into account the published URLs (currently the actions have arguments that affect the publishing URLs)
• I can think of two options:
  1. snapshot and online-version-bump still produce a "ready.to-publish" github artifacts (a single one or separate artifacts for metadata and targets). publish workflows then use these artifacts -- the default github-pages publish workflow/action could then have a way to define which URL paths to use for the publish.
  2. snapshot and online-version-bump don't produce GH artifacts at all, they just inform the workflow that a publish can be made. The publish workflows then run separate command(s) to produce the artifacts and then publishes them

The upside of option 1 it that it keeps the publish workflow/action quite simple: just handle the the GH artifacts. It does mean both snapshot and online-version-bump have to produce those artifacts though.

[jku]

A related note: we may want to annotate repository publish in the git repo itself. The light weight option is a branch that follows main and is updated in the publish action: the "publish" branch always points to the last commit that has been published.