-
Notifications
You must be signed in to change notification settings - Fork 28
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
SHIP-0004: Build Environment Variables #27
SHIP-0004: Build Environment Variables #27
Conversation
/hold |
release note formattting is not quite right ... nothing is rendoring underneath the heading as I currently view it |
otherwise, since I see no one assigned, am I correct @coreydaley that in addition to the hold you have here, this is still a work in progress item, and we should hold off on reviewing? Or should I add this to the queue and dive in? thanks |
|
These tests won't pass until shipwright-io/build#817 merges |
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 pending the type for the env var array per my comments in your associated build PR nothing immediate that I see @coreydaley
I did ask a question around the kind / local registry thing ... maybe a change needed there based on the answer (but I'm guessing no)
and lots of useful libs around BATS and the e2e's .... I plan to wait until all that merges so I can build off of it for adding an e2e for ship build run <name> --follow
:-)
test/e2e/e2e.bats
Outdated
buildrun_name=$(random_name) | ||
|
||
# create a Build with two environment variables | ||
run shp build create ${build_name} --source-url=https://github.com/shipwright-io/sample-go --output-image=my-image --env=VAR_1=build-value-1 --env=VAR_2=build-value-2 |
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.
@otaviof @coreydaley - I have not tried it yet, but perhaps you all have. With the kind/local registry stuff we are employing, is it correct to say that by default we do NOT need credentials to push images to it?
And hence why I don't see cred creation 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.
Yes, we can assume the registry won't have any authentication, since we are in complete control of the container registry in use after #43 👍🏼
/approve |
/hold just in case, as we need to vendor in the associated build PR |
some cross referencing with shipwright-io/build#817 (comment) and shipwright-io/build#817 (comment) summary
|
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.
Some comments left on the pull-request, and I'm having issues with the Go modules changed. As per:
$ go mod vendor
go: github.com/shipwright-io/[email protected] (replaced by github.com/coreydaley/[email protected]): version "v0.0.0-20210927153915-3175d47a83e4" invalid: unknown revision 3175d47a83e4
go: downloading github.com/coreydaley/shipwright-io-build v0.0.0-20210927153915-3175d47a83e4
go: downloading github.com/spf13/cobra v1.2.1
go: downloading k8s.io/apimachinery v0.20.6
go: downloading k8s.io/client-go v0.20.2
go: downloading k8s.io/api v0.20.6
go: downloading github.com/onsi/gomega v1.10.3
go: downloading k8s.io/cli-runtime v0.20.2
go: downloading github.com/texttheater/golang-levenshtein/levenshtein v0.0.0-20200805054039-cae8b0eaed6c
go: downloading k8s.io/utils v0.0.0-20210111153108-fddb29f9d009
go: github.com/shipwright-io/[email protected] (replaced by github.com/coreydaley/[email protected]): version "v0.0.0-20210927153915-3175d47a83e4" invalid: unknown revision 3175d47a83e4
Same with go mod tidy
, for the record.
test/e2e/e2e.bats
Outdated
@@ -2,25 +2,82 @@ | |||
|
|||
source test/e2e/helpers.sh | |||
|
|||
setup() { | |||
load 'helpers/bats-support/load' |
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.
As much as I like the syntax and the practical effects of the "bats-support" helper functions, I don't like the idea of copying the whole project. I think we could create our own helper functions and make use local tools like grep
, awk
and others.
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 seems a bit silly to basically re-write a library that is provided by the framework that we want to use.
I would be open to adding it as a submodule.
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.
hmmm ... I see both sides here
don't know the answer to this question: even though bats is not a go project, can we use go mod to vendor the repo in, and then load from the vendored location?
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 seems a bit sketchy to me, I think I would rather the submodule.
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.
sorry multitasking too much this AM ... can you clarify / further explain what you mean by submodule ?
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.
looking at @coreydaley 's 2150530 I actually agree with him @otaviof that we should use git submodules for this ... I agree go mod vendoring should not be used for a project like BATS which is not go based
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 vendoring the external dependency is easier due being part of regular commits, we include the vendor
directory in the project itself, as usual, and it makes everything simpler IMO. Git submodule is something I only have bad memories, and compared to the vendor
option, it does require extra steps.
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.
Git sub-modules are really the de-facto way to include external libraries like this in your repository.
Vendoring a project that has absolutely no Go code seems pretty sketchy.
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.
Then, I think we can benefit from a more in-depth discussion about the git-submodules, @coreydaley. Seems a bit too much given we need a couple of assertions we can easily achieve with shell-script.
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.
sounds like another topic for Monday / community meeting
pkg/shp/flags/build.go
Outdated
@@ -14,14 +15,14 @@ func BuildSpecFromFlags(flags *pflag.FlagSet) *buildv1alpha1.BuildSpec { | |||
spec := &buildv1alpha1.BuildSpec{ | |||
Source: buildv1alpha1.Source{ | |||
Credentials: &corev1.LocalObjectReference{}, | |||
Revision: pointer.String(""), | |||
ContextDir: pointer.String(""), | |||
Revision: pointer.StringPtr(""), |
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's the reason for this change?
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 there was an issue when one of the dependencies was updated.
Correct, since I am pulling in source from my own branch until my other api changes merge in shipwright-io/build. |
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.
so @coreydaley do you plan to add any valueFrom secret/configmap related options on the build/buildrun creates you added ... i.e. a --valueFromSecret= sort of thing
No, @adambkaplan and I discussed it yesterday. I also don't think that |
/hold cancel |
CI is green, including the e2e's I'll /approve and will let @otaviof or @adambkaplan make the final pass for lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gabemontero 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 |
/hold |
oops / apologies .... you want #51 to merge first ? |
/hold cancel |
ok, now @otaviof @adambkaplan with everything vendored in at the right levels and green tests, I'll wait on an lgtm and let one of you sign off since I already put the approve label previously |
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.
On the final pass I found a couple of items, overall it looks good though!
removing dependency for user to have to install BATS
@otaviof updates have been made per your suggestions. ptal |
/lgtm |
Changes
Submitter Checklist
See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes
Adds the ability to specify environment variables for
Builds
andBuildRuns
as akey=value
pair via the command line using the--env
flag.Environment variables specified for a
BuildRun
will override those in theBuild
.