Skip to content

Migration: release providers → go/forge

The release layer has been extracted:

What Now lives in
Provider, Release, ReleaseAsset, the registry, ReleaseSourceConfig gitlab.com/phpboyscout/go/forge
Token resolution (ResolveToken, TokenConfig, AuthConfig) gitlab.com/phpboyscout/go/forge
releasetest gitlab.com/phpboyscout/go/forge/test
Published mocks gitlab.com/phpboyscout/go/forge/mocks
direct provider gitlab.com/phpboyscout/go/forge/direct
GitHub / GitLab / Gitea+Codeberg / Bitbucket providers go/forge-github, -gitlab, -gitea, -bitbucket

Auth moved with the contract deliberately: it lived in pkg/vcs while the contract lived in pkg/vcs/release, and every real provider needs both. Shipping them apart would force an out-of-tree provider author back onto go-tool-base.

Repoint imports

-import "gitlab.com/phpboyscout/go-tool-base/pkg/vcs/release"
-import "gitlab.com/phpboyscout/go-tool-base/pkg/vcs"
+import "gitlab.com/phpboyscout/go/forge"

release.Providerforge.Provider, vcs.ResolveTokenforge.ResolveToken, and so on. The symbols keep their names.

Mocks and the test double follow suit — alias the imports, since a bare mocks or test collides:

-import mockRelease "gitlab.com/phpboyscout/go-tool-base/mocks/pkg/vcs/release"
-import "gitlab.com/phpboyscout/go-tool-base/pkg/vcs/release/releasetest"
+import mockRelease "gitlab.com/phpboyscout/go/forge/mocks"
+import forgetest "gitlab.com/phpboyscout/go/forge/test"

Provider imports

Providers now register from their own modules:

-import _ "gitlab.com/phpboyscout/go-tool-base/pkg/vcs/gitlab"
+import _ "gitlab.com/phpboyscout/go/forge-gitlab"

A tool supporting one forge can now import only that provider and shed the other vendor clients entirely — which is the point of the split.

Register returns an error

It no longer overwrites a duplicate source type silently:

-forge.Register("s3", factory)
+if err := forge.Register("s3", factory); err != nil {
+    panic("myforge: " + err.Error())
+}

Silent overwriting let one blank import displace another with no diagnostic, and initialisation order decided the winner. Use forge.Unregister to replace a provider deliberately, or forge.Registered to register conditionally.

What stayed in GTB

  • pkg/vcs.ConfigFromContainable — the go/config bridge to the narrow forge.Config seam.
  • pkg/vcs/githubremoved in a later wave. The auth and SSH-key-upload paths GTB actually used (the OAuth device-login flow, SSH key upload) moved into the forge provider capabilities consumed by pkg/setup/forge. The wider, unused client surface — pull requests, repository creation, file contents — was deleted rather than carried; giving one forge those capabilities while the others lack them is deferred to the go/forge provider-contract-widening spec, to be restored across every provider in lockstep in a future wave.
  • pkg/vcs/repo — the props/config adapters for go/repo.

Three package-level tunables were removed

setup.MaxChecksumsSize, setup.MaxBinaryDownloadSize and setup.DefaultRequireChecksum were exported mutable variables. They are gone.

They raced under t.Parallel() — two tests had to run serially because of it — and scoped a setting to the whole process rather than to the updater that needed it.

Size bounds are now constants plus per-updater options:

-setup.MaxBinaryDownloadSize = 2 << 30
+setup.NewUpdater(ctx, props, "", false, setup.WithMaxBinaryDownloadSize(2<<30))

setup.DefaultMaxChecksumsSize and setup.DefaultMaxBinaryDownloadSize hold the defaults. WithMaxChecksumsSize and WithMaxBinaryDownloadSize raise them.

Checksum enforcement moves to the tool-author baseline on props, beside the other baselines like UpdatePolicy:

-func init() { setup.DefaultRequireChecksum = true }
+requireChecksum := true
+props.Tool.Signing.RequireChecksum = &requireChecksum

It is a pointer so "unset" stays distinguishable from "explicitly false". Runtime update.require_checksum config still overrides it, and the precedence is otherwise unchanged.

Documentation