Skip to content
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

Conversation

jjbustamante
Copy link
Contributor

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

@jjbustamante jjbustamante marked this pull request as ready for review September 1, 2022 21:46
@codecov-commenter
Copy link

codecov-commenter commented Sep 1, 2022

Codecov Report

Merging #1027 (a4d08d1) into main (411ffa0) will increase coverage by 0.38%.
The diff coverage is 95.45%.

@@            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     
Impacted Files Coverage Δ
pkg/cnb/env_vars.go 86.36% <93.93%> (+22.72%) ⬆️
pkg/cnb/project_descriptor.go 88.75% <100.00%> (+7.32%) ⬆️
pkg/reconciler/network_error_reconciler.go 88.88% <0.00%> (ø)
pkg/apis/build/v1alpha2/build_pod.go 98.65% <0.00%> (+0.04%) ⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@jjbustamante jjbustamante added this to the kpack 0.7.0 milestone Sep 1, 2022
@jjbustamante
Copy link
Contributor Author

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.

@samj1912, @tylerphelan

@sambhav
Copy link
Contributor

sambhav commented Sep 2, 2022

@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.

@jjbustamante jjbustamante force-pushed the bugfix/issue-1017-support-correct-specification-of-project-descriptor branch from 9b07b40 to 3245661 Compare September 2, 2022 16:16
@jjbustamante
Copy link
Contributor Author

@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.

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.

@jjbustamante jjbustamante force-pushed the bugfix/issue-1017-support-correct-specification-of-project-descriptor branch from 3245661 to 0e3c15f Compare September 2, 2022 16:26
ioutil.WriteFile(projectToml, []byte(`
[_]
schema-version = "0.2"
[[io.buildpacks.env]]
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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)

ioutil.WriteFile(projectToml, []byte(`
[_]
schema-version = "0.2"
[[io.buildpacks.env]]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[[io.buildpacks.env]]
[[io.buildpacks.env.build]]

Copy link
Contributor

@sambhav sambhav left a 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?)

@jjbustamante
Copy link
Contributor Author

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

func getEnvVariables(d descriptorV2) []envVariable {
env := d.IO.Buildpacks.BuildEnv.Env
if env == nil {
env = d.IO.Buildpacks.Env
Copy link
Contributor

@tylerphelan tylerphelan Sep 2, 2022

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

@samj1912 @tomkennedy513 @matthewmcnew @jjbustamante

Copy link
Collaborator

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good 👀 @samj1912 !

@sambhav
Copy link
Contributor

sambhav commented Sep 2, 2022

So IIUC

highest to lowest precedence -

  • io.buildpacks.build.env
  • io.buildpacks.env.build
  • io.buildpacks.env
    ?

@jjbustamante
Copy link
Contributor Author

  • io.buildpacks.build.env
  • io.buildpacks.env.build
  • io.buildpacks.env

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 build.env and env.build can be the same, with two fields but if I get an error trying to parse the toml file then I will have to create a different struct to try to parse the case env, right?

@jjbustamante
Copy link
Contributor Author

I am not totally happy, but I did a refactor to include the compatibility for all the 3 cases:

  • io.buildpacks.build.env
  • io.buildpacks.env.build
  • io.buildpacks.env

If anyone have suggestions about the approach, let me know.

@jjbustamante jjbustamante force-pushed the bugfix/issue-1017-support-correct-specification-of-project-descriptor branch from e15e027 to e5ad236 Compare September 6, 2022 16:22
@jjbustamante jjbustamante force-pushed the bugfix/issue-1017-support-correct-specification-of-project-descriptor branch from 5f13ba2 to ca3f513 Compare September 7, 2022 15:18
pkg/cnb/env_vars.go Outdated Show resolved Hide resolved
@tomkennedy513
Copy link
Collaborator

@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>
@jjbustamante jjbustamante force-pushed the bugfix/issue-1017-support-correct-specification-of-project-descriptor branch from bdb3abf to 37f948d Compare September 7, 2022 20:10
@jjbustamante
Copy link
Contributor Author

@jjbustamante can you rebase this pr since its out of date

Done @tomkennedy513
I also squashed the commits.

@tomkennedy513 tomkennedy513 merged commit ad6c587 into buildpacks-community:main Sep 7, 2022
@jjbustamante jjbustamante deleted the bugfix/issue-1017-support-correct-specification-of-project-descriptor branch September 7, 2022 20:26
@jjbustamante jjbustamante self-assigned this Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support correct specification of project descriptor
7 participants