Checkout Strategy Merge - Merging before a plan

[Charg]

First, huge thanks to the creators and maintainers of this project. Atlantis is helping us create a more autonomous engineering org.

---

Our Configuration
We have checkoutStrategy: merge set in our helm definition

The Question
In production we had two PRs (same repo) open against the same project/workspace/directory. The locking worked as expected, and locked the first PR (PR1) project. The second PR (PR2) is created and gets a message notifying it that the project is locked.

Work continued on PR1 and eventually we ran atlantis apply and merged to master. This lifted the lock from PR1.

Since the lock was lifted we were now able to run atlantis plan on PR2. The output from the plan showed deletions from the work that was just merged in PR1.

Is this the expected behavior, even with the checkoutStrategy set to merge?

[lkysow]

This sounds like #804 which was somewhat mitigated by #867. Did you see the diverge warning on your plan?

[Charg]

Yes, the comment from atlantis did contain a waning about the branch diverging. That's awesome, I didn't know that warning existed.

What are your thoughts on adding an option to always force clone on divergence? Maybe adding a new checkout strategy called merge-always.

[lkysow]

I don't think that will work. There's some concerns I had in the original ticket. Basically we're not guaranteed to have the whole PR locked, maybe only some directories, so when it's unlocked some of the directories might be half way through a plan or apply cycle and we can't reclone for those projects.

[Charg]

After looking at the code I see what you're talking about. I wonder if each project should be its own branch off of the PR branch. The branch doesn't really have to exist after the plan is generated 🤔 But that's a decent size change and another conversation.

In this case, what are your thoughts on taking the divergence option a step further and having an option to block applies if divergence is detected? This would add an extra safety net preventing users from shooting themselves in the foot if they accidentally don't notice that they are removing objects because they glanced over the warning.

[lkysow]

Sure that could work. You could also set "require branches be up to date" in github (or your vcs) and then use the mergeable apply requirement.

[enummela]

I ran into this situation as well. For now I'm simply wondering if any method exists such that a user could make Atlantis reclone when the branch diverges? Here are a couple of methods I suspect might cause a reclone:

• In the PR run unlock and then plan.
• Close the PR and then open a new one.

If someone could confirm then it would be much appreciated 🙂

[dupuy26]

Closing the PR and opening a new one would definitely solve any divergence, especially if the new PR is based on master (but with merge strategy it should work even if the new PR has the same old branch point as the old PR).

As far as I know, running unlock does not re-clone or re-merge, but that would be a reasonable thing to do, and since a global (not per-project) unlock also discards all plans, it should be safe to re-clone/re-merge from master when that is done (doing the re-clone/re-merge on plan commands can be undesirable, especially for per-project planning).

[bschaeffer]

This feels a bit unresolved to me. If atlantis has a lock on PR for a project, and there are other competing projects, shouldn't merging always be a valid strategy.

I am struggling to think of a situation where always merging against master is an invalid approach. If PR1 has the lock, PR2 makes changes in the same project, atlantis IS guaranteeing that PR2s changes won't be merged and reverted by a PR1 atlantis apply. If that paradigm can't be trusted, if we can't rely on locking to ensure valid plans, then what are the locks even for?

[bschaeffer]

I guess I just want a solution where I merge PR1 and PR2 does not try to revert the changes PR1 just landed. How do we configure atlantis to do the right thing and never revert changes that have landed and been applied in master?

[bschaeffer]

Actually, the more I think about it, PR2 cannot be planned at all until PR1 is merged, so the merging and the files changing are guaranteed and it seems like a bug to not rebase against the latest master when planning.