If "Update now" is failing on your repo, re-run the installer to recover

[elijah286]

Short version: if updating your LabVIEW CI tooling fails with a git authentication error, the access token your repo uses for updates has expired. The quickest way back is to re-run the installer — it keeps your existing settings and issues a fresh token in one pass.

---

Are you affected?

Open the most recent Apply LabVIEW CI update run in your repository. If it failed at the Checkout step with this:

fatal: could not read Username for 'https://github.com': terminal prompts disabled

then yes. The run dies in well under a minute and never reaches the update itself, so nothing in your repo was changed.

If your updates are working, nothing here applies to you.

What happened

When you installed LabVIEW CI, you may have added a personal access token as a repository secret named TOOLING_UPDATE_TOKEN. It exists for one reason: GitHub does not permit a workflow's built-in token to modify files under .github/workflows/, and most tooling updates change those files.

Personal access tokens expire on a schedule. When yours did, the update workflow should have fallen back to the built-in token and simply deferred the workflow files — that path exists and works.

It didn't, because the fallback only handled a missing secret. An expired token is still a perfectly good non-empty value, so it was selected anyway and handed to the checkout step, which failed immediately with an error that mentions neither the token nor the secret.

That's a bug on our side, not anything you configured wrong. An expired token ended up being worse than no token at all.

What's fixed

As of v4.15.1, the update workflow verifies the token before using it. If it's expired, scoped to the wrong repository, or otherwise unusable, the update still runs on the built-in token, and the run summary names the token and explains how to replace it — instead of failing with a raw git error.

There's a catch, and it's why this post exists: that fix ships inside the update workflow. If your updates are already broken, you can't receive the fix through an update. You need one pass that doesn't depend on the stored token.

Recommended: re-run the installer

The installer doesn't use the stored secret. It uses a token you supply in the browser at install time, so it works even when updates are stuck.

1. Open the configurator: https://elijah286.github.io/LabVIEW-CI-with-Containers/integrate.html
2. Enter your repository as owner/name. The page gives you a pre-filled token link with exactly the permissions it needs — follow it and paste the token back in.
3. On the re-install panel, leave Keep the existing settings ticked. Your capabilities, LabVIEW version, and platform selections carry over; this is not a fresh start.
4. Leave Remove old tooling files no longer used ticked. If you've been on an older version for a while, this clears out files that are no longer part of the pipeline and can otherwise linger and break builds.
5. Make sure Enable one-click tooling updates is ticked. This stores a fresh TOOLING_UPDATE_TOKEN, replacing the expired one, so ordinary updates work again afterwards.
6. Review and merge the pull request it opens.

This lands you on v4.15.1, the current stable release, which includes the fix described above. You don't need to change the version selector — the default is correct.

Your CI history, your dashboard, and your configuration are untouched. Only tooling files are replaced.

Or just replace the token

If you'd rather not reinstall, replacing the secret works too:

gh secret set TOOLING_UPDATE_TOKEN --repo <owner>/<name>

Paste the token when prompted — don't pass it as a command argument, where it lands in your shell history. Then confirm it actually saved, because this is the step that quietly doesn't happen:

gh api repos/<owner>/<name>/actions/secrets \
  --jq '.secrets[] | "\(.name) updated=\(.updated_at)"'

The timestamp must be from today. Creating a token on GitHub's settings page does not put it in your repository — it still has to be written into the secret.

The token needs Contents: Read and write and Workflows: Read and write, and if it's a fine-grained token, your repository must be explicitly selected under Repository access. Then re-run Update now.

Preventing the next one

Personal access tokens will expire again. Two things help:

• Give the token a long expiry, or set a calendar reminder before it lapses.
• If you're on v4.15.1 or later, an expiry stops being an outage. The update still applies everything except workflow files and tells you plainly what needs rotating.

We're also looking at replacing the token entirely with a GitHub App, which mints short-lived credentials per run and never needs rotating. If that's interesting to you, say so below — it affects how we prioritise it.

Questions

If you hit something this doesn't cover, reply here with a link to the failed run and we'll take a look.