Test Details Overview

Run Build & Deploy on the tag it builds

Build & Deploy used to create the tag in its first job and have the
build jobs check that tag out, so a run's own commit was the branch
head it started from while the packages came from the version commit
one step ahead. Anything that records the run's commit, including the
attestations the next change adds, would have named the wrong one.

Tagging moves to its own workflow, Tag Build, which keeps the schedule
and the manual trigger, creates the tag and then starts Build & Deploy
on it with gh workflow run, the one way a GITHUB_TOKEN may start a
workflow. Build & Deploy now runs on a tag ref, checks out that ref as
any workflow does and takes the tag name from it, so it can also be
started by hand on an existing tag to rebuild it. A first job refuses
to run on anything but a build tag.

The upload steps run only when the bucket credentials are present,
which lets a fork build and verify packages without them.

__________

Type: commit

Hash: 04be2b38e180f9babe6ab1156f521da031cba4e8

Created: yesterday

__________

gr0v1ty/nano-node:04be2b38e180f9babe6ab1156f521da031cba4e8