GitBlixt
Docs Navigation

Instance Updates

A GitBlixt instance can follow another one (the upstream) and take its updates: every push to the default branch of the upstream's GitBlixt source repository is announced to its subscribers, which can merge it into their own GitBlixt repository and redeploy themselves. Everything is managed under Admin → Updates, which needs the root-only updates:manage permission: an update runs the upstream's code with access to Docker.

Subscribing to an Upstream

  1. Enter the upstream instance's URL (for example https://gitblixt.com; its repository URL works too) under Upstream and click Subscribe.
  2. Click Create a gitblixt repository from the upstream (or pick an existing fork as the Local GitBlixt repository). Updates are merged into its default branch, so your own changes there are kept.
  3. Choose what happens when an update arrives.

Modes

  • Notify tells admins an update is available.
  • Review also fetches it into the local repository so the page shows its diff; an admin clicks Merge & deploy.
  • Auto merges and deploys it as soon as it arrives.

An update that conflicts with your changes opens a merge request from an upstream-sync/<sha> branch instead. Resolve it and merge it; the update then deploys.

Publishing Updates

To publish, pick the Source repository under Publishing. Only public repositories are listed: subscribers fetch it without credentials. Pushes that reach it through a pull mirror are not published.

Self-Deploy

Deploying builds the merged commit as the image gitblixt-self:<sha> and rolls the GitBlixt Swarm service onto it (start-first, with automatic rollback). This requires GitBlixt to run as a Swarm service named gitblixt, or the name set in GITBLIXT_SERVICE_NAME. The update is marked deployed once the new container boots; a deploy with no progress for 30 minutes (the container never came up, or Swarm rolled it back) is marked failed, and Retry deploy runs it again.

The local repository's own CI may deploy GitBlixt too, so a deploy waits while a pipeline on its default branch is unfinished. After an hour of waiting the update is marked failed and admins are notified; cancel the stuck pipeline and retry. While an update has failed or has conflicts, admins see a red banner on every page linking to it. If that pipeline deployed the update's commit, the update is marked deployed without building it again. A pipeline that starts mid-build makes the self-deploy stop before touching the service.

Self-deploy needs a single-node Swarm: the image is built on, and only exists on, the node running GitBlixt. Older gitblixt-self images are removed on each deploy, keeping the running one for rollback.