* add .devcontainer to .gitignore
* allow AzureDevOps host to be specified in the user_config
* fix spacing issues
* gofmt
* fixes to cmd and update to approach
Co-authored-by: atlantisbot <lkysow+atlantis@gmail.com>
* allow user to pass gh-app-key directly instead of filename
* start fixing tests
* fix make test
* update website with info about new flag
* Apply suggestions from code review
Co-authored-by: Roberto Hidalgo <un@rob.mx>
Co-authored-by: Roberto Hidalgo <un@rob.mx>
* 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
* Add `--autoplan-file-list` server flag to allow modifying the list of files that trigger planning.
* Set default value for `--autoplan-file-list` and add `terragrunt.hcl` to the list.
* Default is handled in server now. No need for it here.
* Fix syntax error test.
* Fix e2e tests
* 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>
- rename gh-app-key to gh-app-key-file for clarity
- change git credentials writer to append a line if there is an existing
.git-credentials file and in the case of the github app to replace the
old github app line
- removed automatically setting --write-git-creds to true when using a
github app and instead requiring this is set specifically
--write-git-creds will create a .git-credentials file and configure
git to use it. To allow authentication with your git remotes over https.
To access private repos.
cmd/server.go:
- Add default empty strings for Azure Devops webhook basic user/pass
server/user_config.go:
- Rename AzureDevopsBasicUser to AzureDevopsWebhookBasicUser to signify
difference from the API call credentials
server/server.go:
- fix azuredevopsClient var
- add Azure Devops to []supportedVCSHosts
- add AzureDevopsRequestValidator for basic auth webhook support
server/azuredevops_request_validator*.go:
- add charset utf-8 to support content-types for webhooks
- start adding validator tests
server/events_controller.go*:
- change azuredevops webhook header to Request-Id
- move Validate() and Basic Auth webhook support to go-azuredevops
- add pull and comment event functions
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
This changeset has two features:
1. We now automatically download the version of terraform specified in
atlantis.yaml configs if we don't already have that version available
locally.
2. Add a new --default-tf-version flag that allows users to set a
default version of Terraform that we will also download if it's not on
disk.
These mean that users don't need to build custom Docker images to just
add terraform versions. It also means that upgrading the version of
terraform that is packaged with the Atlantis Docker image won't cause
issues for existing users because as long as they're running with
--default-tf-version, Atlantis will always use that version.
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.
