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
- Click Subscribe to gitblixt.com, or enter another upstream's URL (its repository URL works too) under Upstream and click Subscribe.
- Choose where updates come from under Update from (see below). With Repository, click Create a gitblixt repository from the upstream (or pick an existing fork as the Local GitBlixt repository); the one-click subscription creates it for you.
- Choose what happens when an update arrives.
Updates arrive with the upstream's next push. To catch up without waiting, for example right after subscribing, click Sync now: it brings in the upstream's head and deploys it whatever the mode, or reports that this instance is already up to date.
Update Sources
- Repository merges each update into the local GitBlixt repository's branch of the same name as the upstream's (created from the update when missing), so your own changes there are kept, then builds and deploys it here. A local branch with no history in common with the upstream's is merged when the two don't conflict; when they do, the update is refused until you delete or reset that branch.
-
Docker Hub
deploys the image the upstream publishes, tagged with the update's commit
(
willc0de4food/gitblixt:<sha>for gitblixt.com; set another image under Docker Hub image). No local repository, merge or build is involved, so local changes aren't possible. The upstream announces a push before its CI has published the image, so the update waits, checking every minute, until the image appears (then admins are told it's ready, or it deploys in Auto mode), and fails after 3 hours without it; Deploy checks again.
Modes
- Notify tells admins an update is available.
- Review also fetches it into the local repository so the page shows its diff, collapsed when it changes more than 50 files or 5,000 lines; 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>
(or, with the Docker Hub source, pulls the published image)
and rolls the GitBlixt Swarm service onto it (start-first, with automatic rollback).
Migrations run as the new container starts. 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.
With the Repository source, 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.