* fix(deps): update module github.com/petergtz/pegomock/v3 to v4 in go.mod
* remove pegomock generate m option, which is not support after v4
* make regen-mocks
* replace pegomock v4 primitive eq/matchers
* convert pegomock v4 Eq/Any matchers
* remove custom models.Repo matcher
* pegomock v4 cannot use result method args
ref https://github.com/petergtz/pegomock/issues/123
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* disable pegomock --use-experimental-model-gen, cause random fail by segv
* make regen-mocks
* fix mock code which uses non experimental pegomock codes
* Add pre and post workflow hook status
* fix missing mocks
* fix pre/post workflow hooks tests
* add cmd output to file
* fix typo
* add cmd output to file on pre workflow hooks
* Add hooks output to web UI
* Remove unnecessary dependencies
* Clean the code and make tests work again
* Make lint happy
* Small fixes, create dedicated UUID generator and docs
* Add missing commentary
* Use matchers instead of mocking for tests and fix e2e tests
* Change 'OUTPUT_FILE' to 'OUTPUT_STATUS_FILE'
* Reduce SendWorkflowHook calls on hooks
* Apply suggestions from code review
Co-authored-by: PePe Amengual <jose.amengual@gmail.com>
Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
* 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>
* fix: add path to DefaultWorkingDirLocker.TryLock()
In the release notes for v0.13.0: https://github.com/runatlantis/atlantis/blob/master/CHANGELOG.md#features-4
> Running in parallel is only supported if you're using workspaces to separate your projects. Projects in separate directories can not be run in parallel currently.
This commit adds `path` as an argument to `DefaultWorkingDirLocker.TryLock()` and includes `path` in the `workspaceKey` used to check if a project is locked. This should allow projects in separate directories to run in parallel.
To my knowledge, there is no functional reason that projects in separate directories cannot run in parallel.
All calls to `DefaultWorkingDirLocker.TryLock()` have been updated. A new unit test `TestTryLockWithDifferentPaths` has been added to test the behavior of locking two separate directories with the same workspace name.
* Add documntation for parallel_plan and parallel_apply options
Co-authored-by: Kevin Snyder <kevinsnyder@ip-192-168-4-61.ec2.internal>
Co-authored-by: Kevin Snyder <kevinsnyder@ip-10-60-10-94.ec2.internal>
* Moved CommandContext and CommandResult to models (#193)
* Moved CommandContext and CommandResult to models
* move from models to command
rename CommandContext -> Context
rename CommandResult -> Result
* moved command related helpers into command package
* move ProjectCommandContext and ProjectResult to command/project package
* move project command context and project result
* revert unrelated code
* move tests
* fix left over
* fix linting
* fix tests
* remove unused import
* fix project context dependencies
* fix depenedecies
* fix typo
Fixes#1539
The branch matcher feature has been introduced in #1383, but the current
implementation was broken and doesn't work at all (#1539).
If my understanding is correct, there are two problems:
(1) The `GlobalCfg` has a default `Repo` instance which always matches
any repositries and branches. Therefore the branch matcher never be
functional.
(2) Validating base branches in
`DefaultPreWorkflowHooksCommandRunner.RunPreHooks()` implicitly assumed
that users customize `pre_workflow_hooks`, but the assumption isn't
always true because it defaults to empty.
For (1), I added a new method `MatchingRepo()` to `GlobalCfg` to check
`BranchMatches()` for a single `Repo` instance.
For (2), I moved validating branch to
`DefaultCommandRunner.validateCtxAndComment()`. Since the method has
already validated meta data of pull request, I think it's suitable place
to check base branches, but please let me know if there is anywhere more
suitable.
* Add a branch regex to the repo.yaml config to allow Atlantis to
accept only pull requests with a given base branch (the branch
a PR would merge _into_).
* `branch` is optional. By default its unset and Atlantis will match
webhooks for pull requests for any branch (no change)
Match any PR,
```
repos:
- id: /.*/
branch: /.*/
```
Match only PRs with master or main base branch.
```
repos:
- id: /.*/
branch: /(main|master)/
```
Some repos have special pull request branching practices. For example,
plan/apply from feature branches merging into master, but separate flows
for merging master into a release branch (where Atlantis isn't used).
Adding a regex allows for flexible workflow options. For example, you
could have Atlantis ignore "release" branches.
