-
Notifications
You must be signed in to change notification settings - Fork 115
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
Refactor/update attempts kubectl apply #751
Conversation
This looks good to me except for the linter error in CI. Are you able to investigate that problem? |
Rubocop works fine locally, I'm unsure why it's creating that error |
Ah, ok I'll take a look at fixing that, then. Sorry about that |
cc @Shopify/pipeline |
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 see if with 2 reties we still see occurrences of this problem
Updated rubocop using bundlelock.
Use method delegate rather than ivars.
Allow specifying a kubeconfig per task in the internal API
Refactor/attempts number and logs
If you rebase with master, you'll get the rubocop changes/fixes. |
I rebased it! just waiting for CI pass🤞 |
Addressing context deadline issues associated with the apply command
Increasing the number of attempts on the apply command will not interfere with the syncing of resources I believe, as the resource watcher is initiated after the apply command and begins syncing here. As well any apply failures will be caught here reaching a DeploymentError before a sync.
The Kubectl apply command is also idempotent, should be safe to retry.