-
Notifications
You must be signed in to change notification settings - Fork 114
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
Allow customising which CRs are pre-deployed #505
Conversation
A corporate CLA was just signed to cover this. |
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.
A few minor things, but this looks good.
@@ -56,6 +56,11 @@ def prunable? | |||
prunable == "true" | |||
end | |||
|
|||
def predeployed? | |||
predeployed = @definition.dig("metadata", "annotations", "kubernetes-deploy.shopify.io/predeployed") | |||
predeployed.nil? || predeployed == "true" |
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.
predeployed.downcase
Should we raise if the value isn't in nil, 'false', 'true'
?
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.
We don't do any of that for prunable
. Do you need those things implemented there too?
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 point. Its probably a good idea to do it in both places, but I won't make it a blocker.
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.
prunable
is explicitly documented as "any other value means false"; restricting to only nil, 'false', 'true'
would be BC-breaking. I'm also not sure why we would want to be case insensitive.
The CI failure is because the lint step can't check out code from remote repos, I'll need to dig into that. For now you can run |
@dturn Resolved. |
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.
Looks good
Could someone maybe trigger another CI run on this? |
CI on updated commit is all green (except for lint, as above) |
@timothysmith0609 What lint issue?
|
Thank you @dturn ! Do you have an estimate for when this might make it into a release? |
Just the fact that lint for external contrib is broken in our CI, not that there was an actual lint error in the code |
We're going to try and release 0.26.5 today. |
What are you trying to accomplish with this PR?
Allow users to determine that certain CRDs should not be considered for pre-deploy. Our specific use-case is a variation on
CronJob
which we want to deploy only once our bare Pod deployment tasks (Rails migrations) have run.How is this accomplished?
CRDs support an annotation which when set to any value other than
true
causes custom resources of that type not to be selected for pre-deploy.What could go wrong?
Not sure.