fix(bitbucket): avoid extra plans using a local LRU

[Almenon]

what

• We only need to run plan if the code changes
• The code changes if the git SHA changes
• Therefore, we can skip the plan if the SHA is the same
• To check if the SHA's are the same, we need to compare against the last SHA
• We store the last SHA in a LRU cache keyed by PR url

why

• to fix Atlantis runs plan when bitbucket pr review request or description changed #3344

tests

Unit tests. I also built the binary and ran Atlantis manually with a few test scenarios.

references

• closes Atlantis runs plan when bitbucket pr review request or description changed #3344

Sidenote: I ran into an error installing pegomock, I suggest upgrading it. I'm not going to upgrade it in this PR because it would change all the generated files and make a scary monster PR.

➜  atlantis git:(main) go install github.com/petergtz/pegomock/pegomock
../go/pkg/mod/github.com/petergtz/[email protected]+incompatible/modelgen/loader/loader.go:10:2: missing go.sum entry for module providing package golang.org/x/tools/go/loader (imported by github.com/petergtz/pegomock/modelgen/loader); to add:
	go get github.com/petergtz/pegomock/modelgen/[email protected]+incompatible
../go/pkg/mod/github.com/petergtz/[email protected]+incompatible/pegomock/watch/watch.go:25:2: missing go.sum entry for module providing package gopkg.in/alecthomas/kingpin.v2 (imported by github.com/petergtz/pegomock/pegomock); to add:
	go get github.com/petergtz/pegomock/[email protected]+incompatible

The latest pegomock is under a different path: github.com/petergtz/pegomock/v4/pegomock@latest

[Almenon]

Note that people are still going to run into extra plans in these scenarios:

• Restart of Atlantis
• Multiple Atlantis servers behind redis, if a request is routed to a different server that doesn't have the SHA in the cache.

So the solution isn't perfect, but it's better than nothing.

[Almenon]

Based on @GenPage 's comment not sure whether the PR can be merged currently, seeking clarification on that.

If we store events in boltDB I'll have to throw out my existing code and rework the PR. I'd need to expire old events so DB doesn't fill up indefinitely, so each key would a value date,sha and every PR I'd have to scan all the keys, filter down to the PR prefix, then delete any key older than 2 months.

It would involve additional work and complexity compared to the current PR, for a situation that would be rendered irrelevant when bitbucket changes their webhooks again, so I'd prefer to keep the PR as-is.

[GenPage]

@Almenon I will not block the PR. It's apparent we don't have any other options regarding this without refactoring the PR model and involving the DB. Please resolve the branch conflicts with go.mod and we will merge.

[Almenon]

@GenPage The conflicts are resolved. Glad to hear it can be merged :D. This will be my first open-source Go PR so I'm excited! It looks like a maintainer needs to approve some of the CI jobs for them to run by the way.

[GenPage]

@Almenon congrats on your first contribution