- Add blackfriday for markdown-to-html comment translation
Azure Devops doesn't support markdown in work item comments
- Restore NewRepo() to original form - removing project parameter
- Add models.SplitAzureDevopsRepoFullName() to handle project name
All Azure Devops URIs need owner, project, and repo. This function
allows us to avoid adding project to NewRepo()
- Update calls to azuredevops.NewClient() to match library requirements
- Add context to azuredevops client to match library requirements
- Basic working CreateComment() and MergePull() support (not widely
tested)
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.
Features:
- remote plans and applies will set a commit status with a link to the
Terraform Enterpise UI where the streaming output can be viewed.
- because remote plans don't support the -out flag, we diff the plan
output between plan and apply phases to ensure users are applying the
plan they expected
How:
We add a new capability to execute a terraform command while
concurrently reading its real-time output and performing actions
accordingly.
Get the Mergeable status of the PR before updating the
Status. This allows for the Status to be a required
Status for merging the PR. This allows us to use the
atlantis status as a Required status, which is the
configuration often used, since most deployments
want to ensure tf plans have all been successfully
applied before merging
Issue: https://github.com/runatlantis/atlantis/issues/453
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.
The new flag takes in a Terraform Enterprise API token and attempts to
write a config file for that token to ~/.terraformrc on startup.
If the file already exists and its contents would change as a result of
us writing it, we error out.
This flag is useful if you're using the TFE backend for any of your
projects as that requires a .terraformrc file with a token for
authentication.
- Use logger for all warnings. Previously we were writing warnings from
cmd/server.go directly to stderr which bypassed our normal log format.
- Add the timezone to log output. This is just really nice to have if
you're looking at old logs.
- Change levels to all be 4 characters: DBUG, INFO, WARN, EROR. This
makes the logs easier to read because it lines up.
- Log when we first receive the request as well as when we send a
response. This makes it easier to see where the request starts and ends.
Introduce new `mergeable` requirement, in similar vein to the `approved`
requirement. Ran `make go-generate` to update mocks accordingly.
This addresses issue #43.
On startup, make a call to the /version endpoint of Gitlab to get which
version we're running. Then use that version to determine whether we
should use the markdown folding syntax where the code is expandable.
Versions of Gitlab < 11.1 don't support the "Common Mark" markdown
format.
Fixes https://github.com/runatlantis/atlantis/issues/315
- Refactoring work from https://github.com/runatlantis/atlantis/pull/314
- Use just the path in templates, not the fully qualified URL since that
is a best practice.
- Add logging to errors when rendering templates.
- Silence help output on cli errors since the help output is now so
large that you have to scroll up to see the errors.
Server startup should be something expected therefore an info rather than a warning.
```
2018/08/28 18:37:50 [WARN] server: Atlantis started - listening on port 4141
```
Signed-off-by: Ben Abrams <me@benabrams.it>
