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/github: removed 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