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

Explicit deactivation of profile via CLI argument #3988

Closed
masih opened this issue Apr 20, 2020 · 6 comments · Fixed by #4054
Closed

Explicit deactivation of profile via CLI argument #3988

masih opened this issue Apr 20, 2020 · 6 comments · Fixed by #4054
Labels
area/profiles good first issue Good for newcomers kind/feature-request priority/p3 agreed that this would be good to have, but no one is available at the moment.

Comments

@masih
Copy link

masih commented Apr 20, 2020

Is there a way to explicitly disable a profile that may have been automatically activated?

@dgageot
Copy link
Contributor

dgageot commented Apr 20, 2020

Hi @masih I'm sorry there's no such feature. Shouldn't be too complicated to add, though

@dgageot
Copy link
Contributor

dgageot commented Apr 20, 2020

All the work happens here:

func ApplyProfiles(c *latest.SkaffoldConfig, opts cfg.SkaffoldOptions) error {

@masih
Copy link
Author

masih commented Apr 20, 2020

Thanks for the quick response @dgageot 🍻

it would be fantastic if that's added. This could even be a flag to disable "auto-activation" and make profile enablement explicit.

I think this would be useful in CI build environment just to assert behaviour and avoid unwanted accidental ones. Outside of that, it could be useful for capturing say integration tests in a profile that are run explicitly against another profile after that profile is deployed. After tests are run one would want to clean up the test resources. That option would assure that I won't accidentally delete application resources as part of cleaning up integration test resources.

Without it the alternative is to avoid auto-activation completely, which results in a less convenient developer experience.

Does that make sense?

@tstromberg tstromberg added the priority/p3 agreed that this would be good to have, but no one is available at the moment. label Apr 21, 2020
@tstromberg
Copy link
Contributor

Makes sense to me. I can definitely see where you would want to be very explicit about which profiles to use in a CI environment. @dgageot - any additional feedback?

@dgageot
Copy link
Contributor

dgageot commented Apr 29, 2020

Profile auto-activation was fixed by #4034
I'll add a way to disable a single profile

dgageot added a commit to dgageot/skaffold that referenced this issue Apr 29, 2020
@masih
Copy link
Author

masih commented Apr 29, 2020

Fantastic many thanks 🍻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/profiles good first issue Good for newcomers kind/feature-request priority/p3 agreed that this would be good to have, but no one is available at the moment.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants