-
Notifications
You must be signed in to change notification settings - Fork 113
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
Local source code feature (using bundle images) #835
Local source code feature (using bundle images) #835
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.
I just checked the ship, I thought @qu1queee wanted a source result for the digest of the image, but that has not made it to the EP. I think would be source-${sourceName}-image-digest
. But can also be separately added.
pruneBundle
is in the API but not implemented. It is fine with me if that gets implemented in a second step, but then it should also not be in the API.
@@ -0,0 +1,16 @@ | |||
--- |
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.
Should this be under the test/data directory as this is not necessarily a good fit for our samples directory? Same applies to other files that you added.
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 figured those could be samples for reference. However, given that they differ only slightly from the Git base counterparts, I have no problem at all to remove them.
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.
A few more small things.
The prune functionality was completely moved into the CLI code. I will make some adjustments to the EP. |
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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: SaschaSchwarze0 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 |
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.
Just some minor items @HeavyWombat
looks good !
@@ -241,6 +241,7 @@ func unpack(in io.Reader, targetPath string) error { | |||
} | |||
|
|||
if _, err := io.Copy(file, tr); err != nil { | |||
file.Close() |
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 it is better to add a defer file.Close()
immediately after the if err != nil ...
block that precedes the io.Copy call
that way, if later changes get inserted in between these lines, we don't lose the call to close
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 searched for an alternative to this, too, but since it is in a for
loop, I think there is no other way to write it. The only other option would be to externalize the loop block into a separate function, but I figured that would be overkill.
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.
yeah I've done the externalize in a for loop before .... I'd be inclined to do that / in my opinion at least do not consider it overkill
// | ||
// +optional | ||
Container *Container `json:"container"` | ||
|
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.
a confirmation / agreement comment here @HeavyWombat @SaschaSchwarze0 @otaviof ... having pointer ref here is conducive to allowing for multiple "implementation" choices for the upload
i.e. we add a new pointer that enables use of a kubectl cp
equivalent
so cool deal
we probably will just need to make sure when we get to that point that there is validation that only allows one of these optional fields related to upload mechanism to be set
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.
Good point. I have not thought about it much, I guess I kind of was under the impression that every "type" of input would eventually end up having their respective individual entry here, therefore making it a pointer reference. Depending on how many other "types" we want to introduce, we could end up with a lot of optional fields, but I guess this is ok.
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.
yeah we have had as many a 4 "options" in some places in openshift ... so yes "seems OK"
bottom line, we are all good here :-) .... occasionally it is just good to provide positive feedback in PRs as well :-)
pkg/apis/build/v1alpha1/source.go
Outdated
@@ -8,11 +8,24 @@ import ( | |||
corev1 "k8s.io/api/core/v1" | |||
) | |||
|
|||
// Container describes the source code bundle container to pull | |||
type Container struct { |
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 do wonder if Container
as the name of a struct type is overloaded, given its use in core k8s
how opposed would everyone be to a more precise name like ImageBundleContainer
or BundleImageContainer
?
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.
Or BundleContainer
as I see a BundleConatinerTemplate
field below
var tw = tar.NewWriter(&buf) | ||
defer tw.Close() | ||
|
||
err := filepath.Walk(directory, func(path string, info os.FileInfo, err error) error { |
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.
According to the doc at https://pkg.go.dev/path/filepath#Walk the newer WalkDir
is more efficient.
Though that is new with 1.16, and we still are at 1.15 per https://github.com/shipwright-io/build/blob/main/.github/workflows/ci.yml
I'm fine if we don't want to take on moving to 1.16 for the project in this PR, but if that is the path we take, how about a TODO comment here to switch to WalkDir
when we do move to 1.16
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 we are fine to move to 1.16 as 1.17 is out there. It was a nice exercise to change it to WalkDir
. Although, I think the improvements will not be that good for us as we require the d.Info()
call on almost all files anyway.
Add quote to make sure empty build names can be detected quickly. Fix `%w` with `%v` as the `%w` is only for `fmt.Errorf`.
With the removal of `Ginkgo` as the default test driver in favour for `go test`, the output becomes quite verbose and more difficult to quickly check. Remove log line from test case to make test output less verbose.
Remove unused variable assignment.
Reference #717 Add new bundle download step container, analog to Git step. Update Build spec to add optional Container field. Add bundle/unbundle functions for the newly added bundle images, where `Bundle` packs a local directory as-is into a one layer container image and `Unbundle` does the reverse by unpacking the layers of an input image into a target directory. This includes the registry push and pull operations, respectively. Update TaskRun setup code to either add a Git step or bundle step.
Apply suggestions from code review. Co-authored-by: Sascha Schwarze <[email protected]>
Bump Go version to 1.16 to be able to use `WalkDir`. Switch to `WalkDir` function.
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.
/lgtm
not blocking on my one remaining comment item, but noting it in the PR in case it ever comes up when some looks at this in the future
return err | ||
} | ||
|
||
file, err := os.OpenFile(target, os.O_CREATE|os.O_RDWR, os.FileMode(header.Mode)) |
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 won't hold the PR up for this, but will cite that per our previous conversation, that I think the os.OpenFile
through the io.Copy
should be in a separate method, so you can employ defer file.Close
in that separate method, and not get the golang complaint about using defer's directly in a for loop.
Changes
Reference #717
Add new bundle download step container, analog to Git step.
Update Build spec to add optional Container field.
Add bundle/unbundle functions for the newly added bundle images, where
Bundle
packs a local directory as-is into a one layer container image and
Unbundle
does the reverse by unpacking the layers of an input image into a target
directory. This includes the registry push and pull operations, respectively.
Update TaskRun setup code to either add a Git step or bundle step.
Submitter Checklist
See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes