Consider replacing jenkins-x/go-scm dependency ?

[vdemeester]

Problem

The git resolver depends on jenkins-x/go-scm for SCM API access. This library is poorly maintained and blocking dependency updates.

Immediate issue: PR #9098 (bump gitea SDK 0.21.0 → 0.22.1) cannot merge because go-scm is incompatible with the new API. The upstream fix (jenkins-x/go-scm#518) has been open since October 2025 with no activity.

Maintenance Status

Metric	jenkins-x/go-scm	drone/go-scm (upstream)
Last merged PR	Sep 2025	Dec 2025
Open dependabot PRs	5+ (months old)	~5 (recent)
Stars	77	184
Gitea driver	Uses gitea SDK	Direct HTTP calls

jenkins-x/go-scm is a fork of drone/go-scm that added a factory package and fake test driver, but switched the gitea driver to use the gitea SDK (which causes this breakage).

Our Actual Usage

The dependency is minimal and isolated (5 files, 2 active):

What we use	go-scm feature
Fetch file content	Contents.Find()
Resolve ref → SHA	Git.FindCommit()
Get clone URL	Repositories.Find()
Testing	fake driver
Client creation	factory.NewClient()

We don't use: PRs, issues, webhooks, reviews, deployments (~80% of the library).

Options

1. Switch to drone/go-scm - More active, no gitea SDK dependency. Requires adding ~200 lines for factory + test mocking.

2. Fork under tektoncd - Maintain only what we need, drop unused code. Ongoing maintenance burden.

3. Minimal custom implementation - Just implement file fetching directly. ~500 lines, no external dependency.

4. Wait for upstream - Risky given maintenance trajectory.

Questions

• Is the maintenance burden of a fork acceptable?
• Should we just implement the minimal file-fetching ourselves?
• Anyone have experience with drone/go-scm as a drop-in replacement?

cc @tektoncd/core-maintainers