1 min read snap, canonical, snapcraft

Autofilling the repository name on snapcraft.io GitHub-build setup

A change for the snapcraft.io publisher dashboard that fills the repository name on the GitHub-build setup form from the snap ID and runs the validation step automatically.

Snapcraft.io is the storefront and publisher dashboard for Snaps. The publisher side has a “GitHub builds” feature where you point a snap at a repo and the store builds it for you. The first-time setup form was a sequence of small repetitive steps; #5347 (merged today) makes the most repetitive of them automatic. This post is the technical write-up. Closes #3319 (internal WD-26505).

What was wrong before

The RepoSelector component asked you to:

  1. Pick a GitHub organisation.
  2. Type the repository name.
  3. Click validate.
  4. Wait for validateRepo to confirm there is a snapcraft.yaml in the repo.
  5. Click “Start building”.

In almost every case the repository name is the same as the snap name — which you have just typed on the previous screen.

What the change does

When you pick an organisation, the component looks for a repo whose name matches the snap ID. If it finds one, it fills the input, runs validateRepo for you, and shows the result inline. The “Start building” button is the only thing left for you to click.

Edge cases

There were three cases I had to design around in review:

  1. The repo exists but has no snapcraft.yaml. The autofill still happens, and a “Re-check” button surfaces the validation error so you can fix the repo and retry without retyping anything.
  2. You want a different repo. You can clear the autofilled value and type a different name. Validation runs again on submit.
  3. You switch organisations mid-flow. Picking a different org clears the input and re-runs the autofill against the new account, so a stale match from the previous org does not stick around.

Implementation

Memoisation at the right boundaries keeps the component from refetching the repo list on every keystroke; the org-pick handler is the only place that refetches. Eleven unit tests cover the success, failure, override, and org-switch paths.

Follow-up

A reviewer comment on #5347 flagged that the validation helper’s name was confusing once the autofill path was added. #5393 (merged 30 Sep 2025) renames it to validateRepoInternal. Four lines, one file, no behaviour change.