-
Notifications
You must be signed in to change notification settings - Fork 165
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
Support correct specification of project descriptor #1027
Support correct specification of project descriptor #1027
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1027 +/- ##
==========================================
+ Coverage 70.14% 70.53% +0.38%
==========================================
Files 122 122
Lines 5658 5726 +68
==========================================
+ Hits 3969 4039 +70
Misses 1313 1313
+ Partials 376 374 -2
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
I just added more unit testing to the merge logic. I agreed that pack has not merging logic. If we agree to avoid that one I can revert to my first commit. |
@jjbustamante what I meant by #1027 (comment) was that if both the fields are set, the new field should have higher precedence and we should ignore the old one. Apologies if it came across as merging the two. We should also have a test case similar to pack where we check that the env vars are from the new field and not the old one. |
9b07b40
to
3245661
Compare
Thanks @samj1912 for the clarification, I removed the merging code and the test case added was also modified. If you defined environment variables in the old version and the on the new version, kpack is going to take ONLY the one defines in the new version. |
3245661
to
0e3c15f
Compare
pkg/cnb/project_descriptor_test.go
Outdated
ioutil.WriteFile(projectToml, []byte(` | ||
[_] | ||
schema-version = "0.2" | ||
[[io.buildpacks.env]] |
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.
@jjbustamante shouldn't this be io.buildpacks.env.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.
That one is defined in L293 see here
In that case, I defined the same variable twice:
schema-version = "0.2"
[[io.buildpacks.env]]
name = "keyA"
value = "valueA"
# check that new declaration must have higher precedence
[[io.buildpacks.build.env]]
name = "keyA"
value = "newValueA"
And then in the assert, I verify the one taken was newValueA
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.
@jjbustamante I meant to comment on the key itself. Left some notes at #1027 (review)
pkg/cnb/project_descriptor_test.go
Outdated
ioutil.WriteFile(projectToml, []byte(` | ||
[_] | ||
schema-version = "0.2" | ||
[[io.buildpacks.env]] |
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.
[[io.buildpacks.env]] | |
[[io.buildpacks.env.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.
The current 'old' code in kpack seems a bit incorrect? See output section of buildpacks/pack#1479
for the old key vs the new key
old pack key - io.buildpacks.env.build
new pack key - io.buildpacks.build.env
old kpack key - io.buildpacks.env? (this seems incorrect?)
Oh! That's interesting. @matthewmcnew @tylerphelan @tomkennedy513 any thoughts on that? I didn't touch that part |
pkg/cnb/project_descriptor.go
Outdated
func getEnvVariables(d descriptorV2) []envVariable { | ||
env := d.IO.Buildpacks.BuildEnv.Env | ||
if env == nil { | ||
env = d.IO.Buildpacks.Env |
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.
let's start a thread here per: #1027 (comment)
The current 'old' code in kpack seems a bit incorrect? See output section of buildpacks/pack#1479
It appears we incorrectly used io.buildpacks.env
while pack
incorrectly used io.buildpacks.env.build
.
We can either support all three or ignore support for io.buildpacks.env.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.
Kpack exists in the pack ecosystem where users would reasonably expect kpack to behave similarly to pack. So, I think we should provide backwards compatibility to both io.buildpacks.env.build
and kpack incorrect key: io.buildpacks.env
.
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 👀 @samj1912 !
So IIUC highest to lowest precedence -
|
I agree with the major reason to do it like this, but, if I am not wrong, I am not able to use the same structs to deal with the 3 cases. The struct to handle |
I am not totally happy, but I did a refactor to include the compatibility for all the 3 cases:
If anyone have suggestions about the approach, let me know. |
e15e027
to
e5ad236
Compare
5f13ba2
to
ca3f513
Compare
@jjbustamante can you rebase this pr since its out of date |
… also adding backwards compatibility with previous version Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
bdb3abf
to
37f948d
Compare
Done @tomkennedy513 |
Problem
The CNB project descriptor v0.2 was updated and the way the environment variables are set was changed. We need to add support for this.
Solution
A new structured was added for parsing the new way of setting environment variables in the project descriptor, but we also kept the previous one for backward compatibility.
Fixes #1017
Signed-off-by: Juan Bustamante jbustamante@vmware.com