v0.108.0

Added

• Registry storage areas can grant fleet nodes access. vk-hub namespaces add --grant
  takes nodes, every node, or node <id>, one node, beside the job rules, on areas whose
  path has no placeholders; * still means every job only. Nodes get no access unless granted.
  The registry's access tab lists these rules by node.
• Removing a fleet node revokes its registry access. Registries managed by the hub refuse
  the removed node's tokens as soon as they hear of the removal, also after they restart.
• vk-hub issues fleet nodes their own registry access. A node granted access to the
  hub-managed registry it uses gets a token for it when it connects, renewed before it expires
  and replaced when the registry or the node's grants change; one no longer granted anything
  is told to drop it.
• Fleet nodes keep the registry access the hub issues them. A restarted node, and any
  vk run on it, has it while it is valid even with the hub unreachable; it goes when the hub
  withdraws it, the node joins again or is removed, or the hub names another registry.
• Fleet nodes reach the hub-managed registry with the access the hub issues them. A node
  with no registry credential of its own uses it for virtkit/ bundles, vk registry pull,
  the Docker relay, caches and build locks, and for a placed job's image pulls once the job's
  token has expired; access that has expired is reported rather than replaced by anonymous
  requests. A job's pipeline images and caches still need the job's own token, and fail once it
  has expired.
• vk build on a fleet node pulls private base images from the hub-managed registry. Base
  images on that registry are pulled with the node's access, or with a placed job's token for
  the job's builds, and a build cache naming that registry without a credential of its own uses
  it too; images on other registries are still pulled anonymously.
• vk run on a fleet node builds from private base images on the hub-managed registry.
  Compose service builds and -f boots pull such bases with the node's access, as vk build
  does.
• Jobs from a fleet node's own gitlab-runner can reach the hub-managed registry. A storage
  area's --grant takes guests for them, within what the node itself is granted; such jobs
  then reach the registry at registry.vk with that access only, never the node's own. Jobs the
  hub places keep their own token alone. Nothing is granted unless an area says so.
• vk-hub comes with the CI tools nodes need. The hub holds a reproducible definition of a
  static git (with git submodule) and git-lfs of its own, labelled with their versions, which
  nodes build to hand their jobs; it declares the hosts its build reaches, cache.nixos.org and
  GitHub's. It has no gitlab-runner, which jobs the hub places never run: a fleet whose nodes run their
  own gitlab-runner adds a definition that includes it. ./update-ci-tools.sh re-pins it.
• Fleet nodes give their jobs the CI tools the hub installed. A node whose config names no
  tools directory hands its jobs the tools it last built for the hub, once it has built any.
• vk-hub keeps its nodes on the CI tools it names. The new tools setting, fleet-wide
  or per node, names the tools nodes should have: the hub's own by default, a definition it
  holds, or none. The hub has every node that lacks them build them, so a new node's jobs get
  git with no operator step. A failed build is shown on the node and tried again after 5
  minutes, then 30 minutes, 2 hours and 6 hours; after that it waits for vk-hub nodes tools,
  which now asks for the setting's tools by default.
• vk build stages can declare the network their RUN steps need. A # vk: allow-name=… allow-ip=… line above a stage's FROM holds its steps to those hosts, on top of
  whatever the build allows; --build-net declared gives a stage that declares nothing no
  network at all. CI job builds honor it too. A build that was refused any host ends by
  listing them.
• Fleet nodes build CI tools with only the network their definition declares. Each stage
  reaches the hosts its Dockerfile declares, within the node's [egress.build], and nothing if
  it declares none. The node keeps what the build contacted and was refused, and a failed build
  names the hosts it was refused.
• Operators download and add CI tools from vk-hub's web UI. The Updates page offers each
  tools definition the hub holds, the built-in one included, as a download, and takes a new
  one as an uploaded tar or gzipped tar of its build context, checked and labelled as
  vk-hub tools add does.
• Fleet nodes never give jobs CI tools that changed after they were installed. A node
  records a checksum of every file of the tools it installs and checks them before each job
  that would get them; a job whose tools changed fails before it starts. The node reports the
  checksums, whether its tools are still intact, and what their build contacted and was
  refused. vk-hub nodes and the audit log flag a node whose tools changed, which the hub has
  build them anew, and one whose tools hold other files than other nodes built from the same
  definition. Tools installed by an earlier vk are rebuilt to record their checksums.
• vk-hub's web UI shows CI tools in full. Each tools definition has a page: the settings
  and nodes that use it, the network each stage of its build declares, each node's build and
  whether its tools are intact, what the build reached and was refused, and the files nodes
  installed, with those that differ between nodes flagged. A node's page shows its tools, their
  check and its automatic build with its next attempt; operators build a failed build's tools
  again from there, and remove a definition no setting names, after confirming.

Full Changelog: v0.107.1...v0.108.0