-
Notifications
You must be signed in to change notification settings - Fork 11
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
Initialize buildpack #1
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I'm going to stop here since it's already a pretty large bit of change I'm asking for. I'll have another go once we've discussed and come to an agreement on what's here.
Converting to draft b/c of 79b9e38#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6R12-R14. Needs paketo-buildpacks/libpak#22 to merge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of the comments are binding. Resolve what you agree with, ignore the rest and merge!
@@ -0,0 +1,71 @@ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally since the helpers all get compiled into the same binary (helper
), separate from the buildpack's binary (main
), I've taken to isolating them all in a separate package. More a style to help navigate than anything technical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed this pattern and ignored it b/c I wanted to unexported functions like 79b9e38#diff-313fab271285a81f27a170c3d599f1e86c757acd469d3479e765d0d1d1160174R31
This suggestion could be implemented with a little reorg (pulling out paths in main). But, given that the helper and the build for this buildpack are doing almost identical things (and require the same imports) it made sense to me that they would live in the same package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. I'm concerned though about the unit testing implications of this being an un-exported function. And once you take that into account, keeping them together often doesn't matter.
} | ||
e.Logger.Infof("Added %d additional CA certificate(s) to system truststore", len(paths)) | ||
|
||
if v := e.GetEnv(EnvCAPath); v == "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
os.LookupEnv()
please. I really hate == ""
as an idiom around environment variables (you'll notice that I prefer [[ -z ${FOO+x} ]]
pretty much everywhere).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't we still want to set it if it was set to an empty string though? We would end up with something like:
if v, ok := e.LookupEnv(EnvCAPath); !ok || v == "" {
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't do the test against empty. If a user sets the value, but sets it to nothing, they deserve what they get.
cacerts/trusted_cas.go
Outdated
layer.BuildEnvironment = libcnb.Environment{} | ||
|
||
certsDir := filepath.Join(layer.Path, "certs") | ||
if err := os.Mkdir(certsDir, 0777); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've used 0755
everywhere else in every other buildpack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but the umask! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Until the spec declares the required umask
of the build container (I'll bet you'll tell me it does :/), we set exactly what we want. Consistency and predictability are key.
* Respects CA from bindings at build time * Contributes exec.d helper that does the same at runtime Signed-off-by: Emily Casey <[email protected]>
* formats code * add tests for GenerateHashLinks and CanonicalName * fail if cert file has muliple PEMs Signed-off-by: Emily Casey <[email protected]>
Signed-off-by: Emily Casey <[email protected]>
Signed-off-by: Emily Casey <[email protected]>
* Explicitly adds ca-cert-helper to build plan * Contructs a single CA certificates layer even if there are multiple ca-certficates plan entries * Readability improvements * License files **NOTE** uses replace directive for libpak, remove before merging Signed-off-by: Emily Casey <[email protected]>
* Adds missing newlines * Adds missing licenses
a0880af
to
509e0bd
Compare
* Refactors Detect * More consistent name and constants Signed-off-by: Emily Casey <[email protected]>
Signed-off-by: Emily Casey [email protected]