-
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
Delete previous plans on autoplan or atlantis plan #1633
Delete previous plans on autoplan or atlantis plan #1633
Conversation
38cb1a9
to
6dfecab
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.
The idea makes sense to me. I'm glad the change in functionality is documented here as well as that's bound to get some questions.
Only thing I'd mention is that the same problem exists with locks I would imagine. Ie. if you amend the change, the lock will still be present. The code for deleting the lock should automatically clean up the data. This is more generic than just deleting the plan file so I'd suggest doing that to harden this implementation.
@@ -45,6 +45,10 @@ atlantis plan -w staging | |||
* `-w workspace` Switch to this [Terraform workspace](https://www.terraform.io/docs/state/workspaces.html) before planning. Defaults to `default`. If not using Terraform workspaces you can ignore this. | |||
* `--verbose` Append Atlantis log to comment. | |||
|
|||
::: warning NOTE | |||
A `terraform plan` (without flags), like autoplans, discards all plans previously created with `atlantis plan` `-p`/`-d`/`-w` |
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 `terraform plan` (without flags), like autoplans, discards all plans previously created with `atlantis plan` `-p`/`-d`/`-w` | |
An `atlantis plan` (without flags), like autoplans, discards all plans previously created with `atlantis plan` `-p`/`-d`/`-w` |
A `terraform plan` (without flags), like autoplans, discards all plans previously created with `atlantis plan` `-p`/`-d`/`-w` | |
A `terraform plan` (without flags), like autoplans, discards all plans previously created with `atlantis plan` `-p`/`-d`/`-w` |
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.
fixed the using-atlantis.md thanks
1b0079f
to
46f6821
Compare
Thanks for the suggestion @nishkrishnan, I think that makes sense. I'll have a look at deleting the locks as well. |
86a14f8
to
4e73bfe
Compare
@nishkrishnan I have added changes to delete the locks. As you suggested I have also considered and tried using one of the already existing methods to delete the lock in a different PR #1704. I am still open to opinions and would be ok if we decide to merge #1704 instead, let me know what you think. |
Was just reviewing open issues and saw this, I think it will also resolve issue #1122 that I opened a while back. |
Hey, @giuli007 thanks for both of your PRs. P.S. |
Hi @srlightbody @angeloskaltsikis thanks for the feedback.
Thanks for the pointers to #1399 and #1122 which are practically the same issue and a PR very similar to this one. I see that @nishkrishnan concern was that all these fixes change the implicit functionality that atlantis currently has to stack up plans triggered by different I guess the advantage of this PR is that it only discards previous plans in case an explicit change has been pushed to the PR (which would trigger autoplan) or an explicit generic My hope is that the changes to the docs in this PR will help making users aware of this behavioural change (I can make them even more explicit if people think that would be useful). |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
@nishkrishnan was there anything more you wanted me to address? Do the changes in this PR look like they could be merged? |
This PR has been automatically flagged as stale and closed because of lack of responses. |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
This is still an issue that we face. Is there a problem with the proposed solution @nishkrishnan ? Can we re-open this please? |
@giuli007 if you want to fix the conflicts we could discuss on emerging this and try it out on the prerelease |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
No stale please 🙈 |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
no stale |
4e73bfe
to
55a37bd
Compare
I finally got round to update this. Out of excess of caution I went to look at the issues that the #1704 PR (alternative to this one) was causing when it was merged into v0.19.5-pre.20220622 and running that use-case (as I understand it: @jamengual Let me know if you need anything else or we can merge it into a pre-release already. |
When using non-default workspaces, plans are stored in pr-and-workspace-specific directories. If a PR is subsequently updated it might happen that some of the plans are no longer relevant with regards to the latest changes. This change ensures that plans are always deleted when a generic plan is triggered either by autoplan or by a "atlantis plan" command. NB Plans are not cleaned up when specific projects are planned explicitly with "atlantis plan -p/-d/-w".
autoplan or generic plan command
55a37bd
to
b3ed274
Compare
I've rebased on top of Any chance that this can be included in a v0.19.9 pre-release ? |
server/events/plan_command_runner.go
Outdated
@@ -64,6 +67,7 @@ type PlanCommandRunner struct { | |||
autoMerger *AutoMerger | |||
parallelPoolSize int | |||
pullStatusFetcher PullStatusFetcher | |||
locker locking.Locker |
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.
This name does not follow the naming conversion of the struct
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.
@jamengual I've now fixed 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.
This looks good to me! Thanks for your contribution 🎉
Thanks @jamengual @lilincmu |
* Delete previous plans on autoplan or atlantis plan When using non-default workspaces, plans are stored in pr-and-workspace-specific directories. If a PR is subsequently updated it might happen that some of the plans are no longer relevant with regards to the latest changes. This change ensures that plans are always deleted when a generic plan is triggered either by autoplan or by a "atlantis plan" command. NB Plans are not cleaned up when specific projects are planned explicitly with "atlantis plan -p/-d/-w". * Also delete locks along with plans when running autoplan or generic plan command * Fix Plan deletion tests after 0.19.8 rebase * Fix Plan deletion tests after v0.19.9-pre.20220912 rebase * Rename struct field to follow camelCase naming convention Co-authored-by: giuli007 <[email protected]>
This PR aims to fix #1624 (and #1122)
When using non-default workspaces, plans are stored in pr-and-workspace-specific directories.
This is often the case when people want to use the parallel plan/apply feature of Atlantis to speedup how long it takes to plan PRs that change a lot of projects at the same time
If a PR is updated after being created it might happen that some of the original plans are no longer relevant with regards
to the latest changes.
The change in this PR ensures that previous plans are always deleted when a generic plan is triggered either by autoplan
or by a "atlantis plan" command.
NB Even after this change plans are not going to be cleaned up when specific projects are planned explicitly with "atlantis plan -p/-d/-w" because it is reasonable to allow someone to progressively build a set of plans for different projects, with different "atlantis plan -p/-d/-w" comments, to then apply them all together.
I've added a couple of phrases to the documentation to clarify this.