Gitlab Token

Workflow-only release. No model code changed; two defects in the shipped workflow did.

It no longer schedules itself. 2026.08.29.1 shipped a trigger:, so installing the extension registered a daily 06:40 job on every host — at a time this author picked, against whatever model instance matched the hardcoded name gitlab-token. On the first host to install it, that instance existed and was managing a production token, and the vendored job landed ten minutes before the operator's own rotation schedule. The cadence belongs to the operator. Set one with swamp workflow trigger set @sntxrr/gitlab-token-rotation --schedule "40 6 * * *" --input rotate=true --input ciVariableProject=group/repo --input ciVariableKey=GITLAB_PUSH_TOKEN, and read the README's new Scheduling section first: both defaults are safe rather than useful, and passing only some of the inputs fails quietly in two different directions.

Propagation is no longer skipped exactly when it is needed. The propagate step gated on the same days-remaining threshold as rotate — but by the time it runs, rotate has already overwritten the managed snapshot with the NEW token, which has a full lifetime ahead of it. The threshold was therefore false precisely when the handover was required: the outgoing value revoked, the replacement never published, and the run reporting success. The gate is now current.observedAt == managed.observedAt, which is true only for the run that produced the secret, since rotate writes the snapshot and the secret in one call with one timestamp while a plain sync refreshes the snapshot alone.

Data references in step inputs are safe-navigated. A step's inputs are evaluated even when its when is false — when gates execution, not evaluation — so data.latest(model,'current').attributes.token killed the run with "No such key: attributes" before any rotation had ever happened. The placeholder that replaces it contains spaces, which GitLab's masking rules forbid, so a masked write of it is refused with a 400 rather than landing a junk value in a live CI variable.

Guarded by tests over the workflow file itself, because no model test could see any of this: trigger is absent, propagate's when mentions observedAt and does NOT mention daysRemaining, and both data inputs are safe-navigated.

Known issue, recorded rather than carried silently: the valid-target preflight reads the raw globalArguments rather than the zod-parsed ones, so an instance relying on the documented baseUrl default fails its own check with baseUrl "undefined". Write baseUrl: https://gitlab.com explicitly. The fix belongs in the check and would have made this release's no-op upgrade entry untrue, so it is deferred.

Upgrading is a no-op for model instances. If you VENDORED a copy of the workflow, no upgrade can reach it — take this one.

Rotation now completes the handover, addresses the right token, and the workflow actually loads.

update-ci-variable — a new method that writes the rotated value into a GitLab CI/CD variable. Without it a scheduled rotation was a timed outage: GitLab discloses a token value exactly once and revokes the outgoing one immediately, so nothing downstream ever received the replacement. It updates and deliberately will not create, because upserting a mistyped key produces a variable nothing reads while the real consumer keeps presenting a revoked value — a silent outage reported as a green run. masked and protected are re-asserted on every write, since GitLab does not carry them forward and a silently unmasked secret prints in the next job log.

tokenName — identify the managed token by name rather than by id. Rotation mints a new id every time, so a configured tokenId names the revoked predecessor from the second run onward: the schedule authenticates fine and then operates on a dead token forever. A rotation schedule configured with tokenId worked exactly once. Names survive rotation. Resolution is exact-match over active tokens only (GitLab's search is a substring match), duplicates are refused rather than guessed between, and setting both identifiers is an error. tokenId remains correct for pinning one specific generation.

Stable aliases — current on the secret spec and managed on the token spec. Every instance was previously keyed by a token id that does not exist until the rotation creates it, so nothing authored beforehand could name one, and findBySpec returns every generation with no CEL construct for "the newest". Read data.latest(model, 'current').attributes.token. managed also fixes a latent workflow bug: the threshold predicate used findBySpec, which still returns the generation just rotated away sitting at zero days remaining, so it stayed true permanently once any token neared expiry and would have rotated on every run.

The rotation workflow now loads. It requires a top-level UUID id and had none, so swamp dropped it with a single warning: swamp workflow list omitted it and swamp workflow run answered "Workflow not found" for a file in the repo. The manifest records that a workflow file exists, not that it parses, so 2026.08.19.2 packaged, published and scored 100% around a workflow that could never be invoked. Fixed, and guarded by a test over the file itself — no preflight check can catch this, since checks run against a model instance and the broken artifact was a workflow.

The workflow is now three jobs: check, then rotate, then propagate. Both rotation gates are unchanged — rotate defaults to false, and the threshold must also hold — so the scheduled run stays read-only. New inputs ciVariableProject and ciVariableKey; leaving either empty skips propagation.

No upgrade action required. tokenName is optional with no default and no persisted resource shape changed. Existing instances keep working on tokenId, including its rotation weakness; moving to tokenName changes which token a rotation acts on and is therefore an operator's edit rather than something an upgrade should do unasked.

Note for GitLab.com Free namespaces: project and group access tokens cannot be created at all — both endpoints refuse even a group Owner, naming a permission no role can grant. Fine-grained personal tokens are the least-privilege option available there.