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

Implementation of target env vars is misleading #1186

Closed
natalieparellano opened this issue Aug 23, 2023 · 9 comments
Closed

Implementation of target env vars is misleading #1186

natalieparellano opened this issue Aug 23, 2023 · 9 comments
Assignees
Labels
good first issue A good first issue to get started with. status/ready type/bug Something isn't working

Comments

@natalieparellano
Copy link
Member

natalieparellano commented Aug 23, 2023

Summary

To provide CNB_TARGET_* vars in the buildpack env, the builder concatenates these to the lifecycle's env. This works because the CNB_TARGET_* vars are added to the "allow list" of env vars that the lifecycle will pass through to buildpacks.

However, this is misleading. Someone reading the code might think that CNB_TARGET_* vars need to be set in the lifecycle's env, but this is not the case (the analyzer reads this data from the run image).

We should use something like WithOverrides to append target vars to the buildpack env in builder.go.

Note this functionality is covered by acceptance so it should be safe to refactor at the unit level.

Context

lifecycle version

0.17.0+

platform version(s)

0.12+

@natalieparellano natalieparellano added type/bug Something isn't working good first issue A good first issue to get started with. status/ready labels Aug 23, 2023
@natalieparellano natalieparellano added this to the lifecycle 0.18.0 milestone Aug 23, 2023
@UtkarshUmre
Copy link

I'm new to this project, but I'm interested in working on this good first issue. May I give it a try?

@natalieparellano
Copy link
Member Author

@UtkarshUmre we would love to have your help with this! Please let us know if there is any additional guidance we can provide that would be helpful

@sarthaksarthak9
Copy link

@UtkarshUmre r u still working on this issue?

@UtkarshUmre
Copy link

yes @sarthaksarthak9 I'm still working on this issue

@sarthaksarthak9
Copy link

yes @sarthaksarthak9 I'm still working on this issue

ok, If u need some help .. I would love to do!!

@UtkarshUmre
Copy link

@sarthaksarthak9 thank you for offering your help. I believe I'm going to need assistance with this one. Where can I contact you?

@sarthaksarthak9
Copy link

@sarthaksarthak9 thank you for offering your help. I believe I'm going to need assistance with this one. Where can I contact you?

you can ask your query here onwards or can dm me on slack

@natalieparellano
Copy link
Member Author

natalieparellano commented Mar 4, 2024

@UtkarshUmre @sarthaksarthak9 - thank you for offering to help with this one. This was fixed in #1309 while addressing a slightly different albeit related issue. I'm going to close this one

@edmorley
Copy link
Contributor

edmorley commented Jul 9, 2024

This is currently in the lifecycle 0.20.0 milestone, however was resolved previously by #1309 which landed in lifecycle 0.19.0 instead. Should the milestone be updated to 0.19.0?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue A good first issue to get started with. status/ready type/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants