Support private git repos and authenticated images as skill sources
Maintainers usually reply within 1 day
@fabianvf is already working on this.
Since Aug 18, 2026.
Assessment
This issue has not been assessed yet.
Description
SkillCard.spec.source clones unauthenticated, so a private repo cannot be a
skill source. Fine for ours, which are public, and blocking for anyone wanting
to keep an internal skill internal, which is most of the reason to use a git
source rather than publishing an image.
The mechanism exists. harness/internal/git/credentials.go has
Credentials{Username, Token, RepoURL, Branch} with an Auth() that the
workspace clone uses, and the loader just does not use it.
The question is whose credentials those are. I lean toward a secret ref on the
SkillCard rather than reusing the workspace token, since the skill source and
the application repo are not necessarily the same tenant. Reusing it would hand
the skill publisher's repo access to anyone who can create an AgentRun, and
would stop a skill source being usable by a run whose application lives
somewhere else. Worth arguing about first, since it is a CRD field either way.
Private images are smaller but belong in the same pass. An ImageVolume pulls
with the pod's imagePullSecrets, so a private skill image works today if the
namespace happens to be set up for it. That is undocumented and untested, and
it fails as a pod that will not start with a message about the image rather
than about the skill.
- decide: secret ref on the SkillCard, or reuse the workspace credentials
- plumb credentials into the loader's clone
- document how a private skill image is pulled, and fail readably when it cannot be
- keep credentials out of the assembled skills root. The loader already excludes
.gitfor this reason, since a tokenized clone URL ends up in.git/config
- Dominant language
- Go
- Stars
- 5
- Forks
- 13
- Avg merge
- 4d 2h
- Merged PRs (30d)
- 27
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from konveyor/agentic-controller
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
konveyor/agentic-controller#305 ·
Maintainers usually reply within 1 day
-
bug stream/controller
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
konveyor/agentic-controller#164 ·
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
konveyor/agentic-controller#124 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
konveyor/agentic-controller#323 ·
Maintainers usually reply within 1 day
-
Provider-aware Gateway verification for aws-bedrock / gcp-vertex-ai, so bad credentials fail at verify rather than mid-runPossibly taken @ibolton336 claimed this 2 days ago. Openenhancement stream/controller
konveyor/agentic-controller#304 · 1 assignee ·
Maintainers usually reply within 1 day
All issues in konveyor/agentic-controller
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area/ambient
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
`autorelease-tag.yml` starts after any run named "💡Fingerprints Update"Possibly taken @Mzack9999 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
projectdiscovery/wappalyzergo#184 ·
-
bug needs-triage P3 tier:2-standard
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
krakenhavoc/cmd_and_ctrl#4990 ·
Maintainers usually reply within 1 day