Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split pkg/server from pkg/api #616

Merged
merged 1 commit into from May 26, 2022
Merged

Split pkg/server from pkg/api #616

merged 1 commit into from May 26, 2022

Conversation

mtrmac
Copy link
Contributor

@mtrmac mtrmac commented May 26, 2022

Signed-off-by: Miloslav Trmač mitr@redhat.com

Summary

Split pkg/server from pkg/api

Ticket Link

N/A

Release Note

External users of pkg/api that refer to the server code now need to use pkg/server.

API clients using pkg/api.NewClient, like github.com/sigstore/cosign, currently end up depending on all the implementation details of the servers, unnecessarily increasing their binary size and supply-chain attack surface.

Instead, move the server code to a new pkg/server (assuming there are no external users of that functionality), and leave pkg/api as a package only providing a client (as it is used in practice, and documented in various places in this repo).

The move includes pkg/api/version.go, because it is only useful with a Go build that specifies the various values at build time, which is unlikely to be the case for any third-party importer of that package.

This shaves over 500 kB from a simple user of pkg/api.NewClient.

API clients using pkg/api.NewClient , like github.com/sigstore/cosign,
currently end up depending on all the implementation details of the servers,
unnecessarily increasing their binary size and supply-chain attack surface.

Instead, move the server code to a new pkg/server (assuming there are
no external users of that functionality), and leave pkg/api as a package only
providing a client (as it is used in practice, and documented in various
places in this repo).

The move includes pkg/api/version.go, because it is only useful
with a Go build that specifies the various values at build time,
which is unlikely to be the case for any third-party importer
of that package.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
@haydentherapper
Copy link
Contributor

LGTM, also worth noting that we'll be recommending the use of the V2 API, and we'll be deprecating the legacy client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants