-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
feat: when using order group, abort plan/apply if any fail #3323
feat: when using order group, abort plan/apply if any fail #3323
Conversation
bc1bf17
to
51f7b76
Compare
@@ -81,6 +81,9 @@ func runProjectCmdsParallelGroups( | |||
for _, group := range groups { | |||
res := runProjectCmdsParallel(group, runnerFunc, poolSize) | |||
results = append(results, res.ProjectResults...) | |||
if res.HasErrors() { |
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.
Could a check be ran here against an opt-out flag?
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.
I can add a flag if you want that. Should that be added on a repo level? In the issue that I referred to, the suggestion was setting this as the expected behaviour.
I'm not sure I see when you would want to opt out of this as you want it to run in a given order, but I'm all ears for what you guys want 👍
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.
I'm not an official maintainer so my opinion is lower than what @krrrr38 mentioned in the issue 😄
It may not be worth it but my thought process was that it changes existing behavior so if any users don't want this it would break their workflow.
And a repo level flag would probably be the most flexible
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.
I agree with @jukie , repo level will be nicer and allows the user to change the behaviour by a flag
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.
Why would anyone want their execution group to continue if it has errors in between?
There's another PR to address this that I think is more involved. #3292 solves essentially what you are proposing, I think it might be more prudent to utilize that feature and deprecate |
The features may be able to work together as this comment points out |
I'll just stay put until you figure out if this is going to be useful or not ;) |
Nevermind. I was corrected in the other PR. It looks like the PR author and GenPage plan to deprecate the |
On the other hand, the terragrunt-atlantis-config repo is currently setup to use the execution order and people who currently use this also complain that a single error will not stop the pipeline. Even if execution-order will be deprecated, i think we should still fix this bug for current users. Then we can have the depends-on implemented and slowly deprecate execution-order thus giving time for people to migrate. |
cc @jamengual @GenPage thoughts? We did the same for the whitelist to allowlist deprecations as well. Slow deprecation to allow people to migrate. |
yes, we can do the same |
Sgtm |
05b5910
to
5de44bf
Compare
@oysteingraendsen can you confirm that you have tested this, not only in unit tests, but end to end in your own setup? If you could test
|
Sorry about the delay. I have been a bit caught up lately. I have tested the points you mentioned and it works for apply, but not for plan. I'll write some tests for plan as well to figure out why it does not work there too. |
@oysteingraendsen If you need help troubleshooting the tests, feel free to ping me here or in Slack. |
c89e05f
to
ec0644b
Compare
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.
LGTM, other than the nitpick comment
36adc3b
to
89d5731
Compare
89d5731
to
8e4026d
Compare
I just verified that it now works. It's ready to be merged from my end now, @GenPage |
…is#3323) * feat: when using order group, abort plan/apply if any fail * feat: add 'abort_on_execution_order_fail' flag on repo level * feat: use runProjectCmdsParallelGroups in version_command_runner * chore: add plan tests --------- Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
…is#3323) * feat: when using order group, abort plan/apply if any fail * feat: add 'abort_on_execution_order_fail' flag on repo level * feat: use runProjectCmdsParallelGroups in version_command_runner * chore: add plan tests --------- Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
…is#3323) * feat: when using order group, abort plan/apply if any fail * feat: add 'abort_on_execution_order_fail' flag on repo level * feat: use runProjectCmdsParallelGroups in version_command_runner * chore: add plan tests --------- Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
what
why
in a prior execution group. This should happen in my opinion.
tests
references