* fix: add path to WorkingDir methods
`WorkingDirLocker` and `WorkingDir` are closely related -- the former acquires a lock, which ensures that the latter can safely operate on a given file path.
In #2131 we added `path` to the `WorkingDirLocker` lock key, but neglected to add the same to `WorkingDir`.
This commit adds `path` as an argument to certain `WorkingDir` methods, and includes `path` in the directory that we use to clone the repository for a given project.
Since `path` can include certain special characters such as `/`, we encode `path` as base32 when using it as part of a file path. This should ensure no special characters are used in the filesystem, and that the value can be decoded if desired (unlike hashes such as md5).
Additional changes:
- All calls to changed methods have been updated, including unit tests
- Mocks have been regenerated for `WorkingDir` and `WorkingDirLocker`
- `working_dir_test.go`
- Commands that operate on filesystem paths have been updated to include the base32 encoded `path` value
- When running `git init`, we include `-b master` as additional arguments, to ensure that `master` is our default branch (expected by the unit tests)
* Try fixing E2E tests
* Fix DefaultPendingPlanFinder
In addition to iterating over `workspaceDirs`, also iterate over `pathDirs`, and use both `workspace` and `path` to build `repoDir`.
* Fix DefaultPendingPlanFinder unit tests
* Fix DefaultProjectCommandBuilder unit tests
Co-authored-by: Kevin Snyder <kevinsnyder@KevinSnydersMBP.lan>
Co-authored-by: Kevin Snyder <kevinsnyder@ip-192-168-1-188.ec2.internal>
* ORCA-731 Force PR authors to rebase if master has diverged (#70)
* initial commit for undiverge apply req
* Update documentation
* Fix existing unit tests
* HasDiverged unit test
* project command runner unit test
* Global config tests cases
* update parser unit tests
* Update project_test unit tests
* Fix linting
* fix test case with logging output
* add space on readme markdown
* Remove unused variable
* remove deprecated flag option
* Use global args struct instead of passing in args
* Fix merge issue
This is two changes:
Replacing all usages of SimpleLogger with it's interface SimpleLogging which makes it easier to swap out loggers going forward
Nukes SimpleLogger in favor of StructuredLogger which allows us to better analyze logs in our log management system we choose.
If there was an error during cloning, we would sometimes print the clone
credentials to the pull request and in the Atlantis logs. This change
ensures we print the redacted clone url.
We also change the redacted clone url to contain "username:<redacted>"
so that if users see the redacted url in logs, they'll know we were
using a credentialed form and so if they try to replicate with curl
they'll know to substitute the correct credentials.
When using --checkout-strategy merge, we were performing the merge
without the --no-ff flag. This meant that if the branch could be merged
via a fast-forward merge (without a merge commit), then later when we
ran git rev-parse HEAD^2 to determine if the repo was at the right
commit, it would fail.
Now we merge with --no-ff which ensures the commit tree will always look
the same and git rev-parse HEAD^2 will always succeed.
This is needed so we can set different commit statuses for plan and
apply phases.
Also, append os env variables to git commands during cloning. This fixed
a bug when running tests where I got an error because git couldn't expand
'~' from its git config to my home directory because the HOME env var
wasn't set.
Automerging merges pull requests automatically if all plans have been
successfully applied.
* Save status of PR's to BoltDB so after each apply, we can check if
there are pending plans.
* Add new feature where we delete successful plans *unless* all plans
have succeeded *if* automerge is enabled. This was requested by users
because when automerge is enabled, they want to enforce that a pull
request's changes have been fully applied. They asked that plans not be
allowed to be applied "piecemeal" and instead, all plans must be
generated successfully prior to allowing any plans to be applied.
This flag can be set to either branch (default) or merge. If set to
branch, we will check out the head branch of the pull request (the
source). If set to merge, we will check out the base branch of the pull
request (the destination) and then attempt to perform a git merge of the
pull request branch. This simulates what will happen if the pull request
is merged.
This allows us to perform terraform commands on what the state of the
repo will be *after* the pull request is merged. This is useful if users
are often opening up pull requests from branches that aren't up to date
with master. With the branch strategy, the terraform plan might be
deleting resources that have been created in the master branch but with
the merge strategy, we merge the branch's changes into the master branch
and so don't have this problem.
