* 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.
* Adding policy_check support into yaml config
* Added policy check model and runtime structs
* Adding BuildPolicyCheckCommand to ProjectCommandBuilder
* Return incorrectly deleted code
* Remove BuildAutoPolicyPlanCommand from ProjectCommandBuilder
* Split runAutoCommand into two functions
runAutoPlanCommand - does what originally RunAutoplancommand was doing
except now it returns CommandResult and []models.ProjectCommandContext
runAutoPolicyCheckCommand - accepts CommandContext, CommandResult, and
[]models.ProjectCommandContext as arguments and runs PolicyCheckStep runner
* Refactor RunCommentCommand
* Remove BuildPolicyCheckCommand and rename StepCmdExec back to TerraformExec
* Add policy step runner logic and conftest interfaces.
* Add show step runner to policy check stage.
* Adding models.PolicyCheckCommand to buildCtx
This also means buildPlanAllCommands call buildCtx twice once with
models.PlanCommand and once with models.PolicyCheckCommand
* Adding new project_command_builder that supports policy_check
* Refactoring PolicyCheck specific logic into a PolicyCheckProjectCommandBuilder
* Moving events.CommandContext to models.CommandContext this will allow me
to remove buildCtx method and move ProjectCommandContext creation into
models package
* Policy Owners might be different types, for that reason we are
refactoring Owners into its own struct with specific keys defining
different owner types
Co-authored-by: Nish Krishnan <nishk@lyft.com>
Co-authored-by: Nish Krishnan <nishkrishnan@users.noreply.github.com>
Previously, given the config:
workflows:
default:
...
We wouldn't actually use the redefined default workfow in our always
existing first repo config. This would mean that the redefined default
was never used unless users explicitly set workflow: default in the
repos array.
This version changes how we parse custom run steps.
Previously we used the go-shlex library to parse the steps but this
caused users issues because they'd have to use weird escaping.
Now we simply pass the step directy to sh -c without any parsing. The
parsing was unnecessary.
This flag will allow users to specify repo config as json instead of
writing a file to disk. This is useful in deployments where disk access
is more difficult, ex. Docker.
This enables atlantis.yaml in all repos, but by default restricts
certain sensitive keys from being used.
The keys apply_requirements, workflow, and workflows can only be
specified in an atlantis.yaml file if explicitly allowed by a
server side repo config.
The repo config file provides the ability to specify a default set of
workflows, and default values for apply_requirements and workflow to use
use on a per repo basis. It also supports applying to a collection of
repos by using regex to match a repo name.
If more than one repo name matches, the values from last repo matched
are used.
This deprecates the --allow-repo-config option
Introduce new `mergeable` requirement, in similar vein to the `approved`
requirement. Ran `make go-generate` to update mocks accordingly.
This addresses issue #43.
