-
Notifications
You must be signed in to change notification settings - Fork 159
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: aaron-prindle If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
b2027b1
to
12925bd
Compare
12925bd
to
1877a7e
Compare
f5527aa
to
6046ed1
Compare
The following is the coverage report on pkg/.
|
@aaron-prindle: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
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.
Looks like it's getting there! I think it's a lot easier to review this on its own vs in the context of #470 :)
My initial feedback at this point is that it seems like we could significantly simplify the options logic, looks like there's a lot of sophistication in there that we probably don't need at this point.
Also @imjasonh had mentioned in #470 (review) adding a README that describes in more detail how the logic works, which would be very handy (esp. for reviewing!)
To use it, run | ||
``` | ||
image: github.com/knative/build/cmd/entrypoint | ||
``` |
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.
im not clear on what it means to run this, is this configuration part of a config file somewhere?
``` | ||
|
||
It used in knative/build as a method of running containers in | ||
order that are in the same pod this is done by: |
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.
maybe this could be two sentences, like:
"It is used as a method of running container in a specified order on the same pod. This is done by:"
image: github.com/build-pipeline/cmd/entrypoint | ||
args: ['-args', 'ARGUMENTS_FOR_SHELL_COMMAND'] | ||
"args":["/kaniko/executor"],shouldWaitForPrevStep":false,"preRunFile":"/tools/0","shouldRunPostRun":true,"postRunFile":"/tools/1" | ||
``` |
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.
im kinda confused about what im looking at here, is this part of a build config?
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 think array brackets are misplaced. Is it like this?
["/kaniko/executor", "shouldWaitForPrevStep": false, "preRunFile":"/tools/0", "shouldRunPostRun":true, "postRunFile":"/tools/1"]
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.
That list corresponds to list of accepted args for entrypoint image I think.
The example shows how a user can just create step with entrypoint
image and pass those args. I think this is the pattern in other cmd files(I think)
args: ['-args', 'ARGUMENTS_FOR_SHELL_COMMAND'] | ||
"args":["/kaniko/executor"],shouldWaitForPrevStep":false,"preRunFile":"/tools/0","shouldRunPostRun":true,"postRunFile":"/tools/1" | ||
``` | ||
*/ |
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.
can we move this to a README in the same dir? ( @shashwathi do you think that makes sense? i think that's not been the norm for other cmds)
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.
Its not the norm but if we are taking the pain to add README file then I would rather have documentation under docs folder instead of scattered README across the repo(exception like test 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.
Would it make sense to add this information to a README file under docs/ then? Or would it make more sense to leave it as a comment (as it is currently) like it is done in the other cmds?
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.
if we are taking the pain to add README file then I would rather have documentation under docs folder instead of scattered README across the repo(exception like test package)
hm i think this might make it hard to find the README tho @shashwathi ? i find that if docs are close to what they document they're often easier to find - unless we link to that README from a README here 🤔
@aaron-prindle it doesn't matter too much cuz we can always move the doc later, so I think create a README in either location for now - the important thing is to have it documented
|
||
// reset paths to new temp dir | ||
options.PreRunFile = filepath.Join(tmpDir, options.PreRunFile) | ||
options.PostRunFile = filepath.Join(tmpDir, options.PostRunFile) |
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.
what do you think about making it so that the Run
function takes the options values as a parameter? Then we can pass in whatever values we want in the test without having to change global state
the options.Load
function could return an options object instead of setting global state
LoadConfig(config string) error | ||
AddFlags(flags *flag.FlagSet) | ||
Complete(args []string) | ||
} |
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.
whats the use case for this OptionLoader interface? seems like in our case we only have one kind of option loader (maybe im wrong tho!). if that's the case, we could simplify this by removing the option loader interface and just using the type we're using
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.
would it work to simplify the option loading to something like what we do with other cmd
executables in build:
Lines 29 to 33 in addfaf4
var ( | |
url = flag.String("url", "", "The url of the Git repository to initialize.") | |
revision = flag.String("revision", "", "The Git revision to make the repository HEAD") | |
path = flag.String("path", "", "Path of directory under which git repository will be copied") | |
) |
e.g. declaring a set of flags?
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 like the idea of providing all image relevant flags in entrypoint/main.go. We can avoid layer of abstraction if its not needed
var arguments []string | ||
if len(o.Args) > 1 { | ||
arguments = o.Args[1:] | ||
} |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
var testCases = []struct { | ||
name string | ||
input Options | ||
expectedErr bool |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
||
var returnCode int | ||
if status, ok := command.ProcessState.Sys().(syscall.WaitStatus); ok { | ||
returnCode = status.ExitStatus() |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
return returnCode, commandErr | ||
} | ||
|
||
func (o *Options) waitForPrevStep() error { |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
}, | ||
}} | ||
|
||
for _, testCase := range testCases { |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
// execute the user specified command | ||
done := make(chan error) | ||
go func() { | ||
done <- command.Wait() |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
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.
Great work. 🎆
Closing in favor of tektoncd/pipeline#448 |
What is the problem being solved?
This PR adds an entrypoint image which is capable of running another command with some pre-run/post-run hooks. The goal of this is to allow for the the entrypoint of a container in a Build Step to have it's entrypoint rewritten by mounting this entrypoint image into the container provided in a Step, rewriting the entrypoint, then running the user container w/ the additional pre-run/post-run hooks. The addition of this image enables the removal of init containers as per #521. This was originally part of #470 but is now split out.
What future work remains to be done?
This PR adds the entrypoint image and release step. The future work involved is modifying Build to stop using init container and use this entrypoint image as a way of making that possible.
TODO: