Transitional GitHub Access
Legacy git-v1 devices only — give an already-deployed private device least-privilege credentials while the fleet migrates to managed artifacts.
This step is only for already-deployed private devices that still update through the
legacy git-v1 path. Those devices run git fetch/git reset against the private
bytegate-edge repository, so they need a stored GitHub credential until they are moved
onto the managed release path.
New deployments, bridge releases, and artifact-v2 capable devices should expect the artifact-v2 target path: ByteGate-managed provisioning, release-channel assignment, and immutable release artifacts. They should not need GitHub credentials stored on the appliance.
Run the setup script
From the bytegate-edge directory on the Pi (the one you cloned in the previous step):
./scripts/setup_github_access.shFollow the prompts
It asks for the GitHub Repository URL first — the HTTPS URL of the bytegate-edge
repo (must start with https://github.com/).
If GitHub access is unavoidable during the transition, create a fine-grained personal
access token for this device. Scope it to the single bytegate-edge repository and grant
only read access needed for code contents. Do not use a broad account-wide token or a
credential that can write to repositories.
Then it prompts for the GitHub Personal Access Token itself — input is hidden as you
type/paste it. The script checks the token against the GitHub API to confirm it can
actually see the repo before continuing, and if git config --global user.email/user.name
aren't set yet, it will ask for those too so future git operations on the device have an
identity.
Field tip
Skip this page for new managed deployments. For legacy private-repo devices only, without this credential the current git-v1 OTA path cannot authenticate to GitHub and update commands will fail.
Last updated on