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

chore: Upgrade smallstep libs #4307

Merged
merged 1 commit into from
Aug 25, 2021
Merged

chore: Upgrade smallstep libs #4307

merged 1 commit into from
Aug 25, 2021

Conversation

francislavoie
Copy link
Member

See smallstep/nosql#12 for context.

Followup to #4291, but this time CGO is gone for good*!

The important deps to upgrade here are smallstep/certificates and smallstep/nosql but I noticed smallstep/cli fell behind so I upgraded that too, which upgraded the rest implicitly.

* At least until another dep decides to introduce something CGO for whatever reason, but let's hope not 😂

@francislavoie francislavoie added this to the v2.4.4 milestone Aug 25, 2021
@francislavoie francislavoie requested a review from mholt August 25, 2021 18:08
Copy link
Member

@mholt mholt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent, this was faster than I thought. Thanks!

@mholt mholt merged commit f6d5ec2 into master Aug 25, 2021
@mholt mholt deleted the upgrade-smallstep branch August 25, 2021 18:16
francislavoie added a commit that referenced this pull request Aug 25, 2021
Run the build with CGO enabled, to verify that the build still passes, even without installing anything extra.

This test should fail if we add any dependencies that optionally uses CGO.

This is an idea I had that could let us know if some change to our dependencies starts optionally using CGO.

The reason this is useful is because Go actually defaults to enabling CGO if the GOOS/GOARCH build target is the same as the current platform, and CGO is supported on that platform. This means some users were Go builds of Caddy implicitly enabling CGO which would fail due to us previously having an indirect dependency on DataDog/zstd. That dependency is now gone since #4307, so we should no longer have any build issues _when enabling CGO_ if we don't have any dependencies which may optionally use CGO.
francislavoie added a commit that referenced this pull request Aug 25, 2021
Run the build with CGO enabled, to verify that the build still passes, even without installing anything extra.

This test should fail if we add any dependencies that optionally uses CGO.

This is an idea I had that could let us know if some change to our dependencies starts optionally using CGO.

The reason this is useful is because Go actually defaults to enabling CGO if the GOOS/GOARCH build target is the same as the current platform, and CGO is supported on that platform. This means some users were Go builds of Caddy implicitly enabling CGO which would fail due to us previously having an indirect dependency on DataDog/zstd. That dependency is now gone since #4307, so we should no longer have any build issues _when enabling CGO_ if we don't have any dependencies which may optionally use CGO.
francislavoie added a commit that referenced this pull request Aug 25, 2021
Run the build with CGO enabled, to verify that the build still passes, even without installing anything extra.

This test should fail if we add any dependencies that optionally uses CGO.

This is an idea I had that could let us know if some change to our dependencies starts optionally using CGO.

The reason this is useful is because Go actually defaults to enabling CGO if the GOOS/GOARCH build target is the same as the current platform, and CGO is supported on that platform. This means some users were Go builds of Caddy implicitly enabling CGO which would fail due to us previously having an indirect dependency on DataDog/zstd. That dependency is now gone since #4307, so we should no longer have any build issues _when enabling CGO_ if we don't have any dependencies which may optionally use CGO.
francislavoie added a commit that referenced this pull request Aug 25, 2021
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.

2 participants