This successfully deletes the atlantis lock and
allows a competing PR to plan, but doesn not delete
the actual plans, so a user can still apply after
the lock is discarded.
This will be investigated in a follow up commit
Also fixed the basic mark down rendering for the discard command
+ Default parallel plans breaks in a lot of autoplan scenarios i.e. with shared workspaces
+ Added a set of e2e tests to check parallel plans and applies
+ Also added an option to the Terraform client to turn off the plugin cache. This was breaking the e2e test suite (never seen this error in practice)
As part of the fix the model is slightly extended
to allow for an extra PlanStatus indicating the absence
of a plan for a project. This allows us to unlock a project
and delete the plan, without having to completely remove the
project status.
That means that atlantis knows there is a project that should
normally have a plan and be accounted for, but the plan has been
deleted/unlocked.
The reason this is important is so that we can't "trick" atlantis
into thinking that the PR can be merged just because we've lost
track of a projectstatus as a result of a manual unlock.
Remove extra quoting and instead add a backslach to each character in
the extra args before appending it to the command.
ex. atlantis plan -- -var key=val will result in:
sh -c "atlantis plan \-\v\a\r \k\e\y\=\v\a\l"
Fixes#697.
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.
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 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
Split single top-level status check into one plan and one apply check.
These checks will also now track the whole pull request status rather
than just the last action.
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.
In Terraform 0.12 and above, you aren't allowed to set -var foo=bar
flags unless the foo variable is actually defined in code. Previously,
we were setting the following variables:
- atlantis_user
- atlantis_repo
- atlantis_repo_owner
- atlantis_repo_name
- atlantis_pull_num
Users could then use these variables if they wanted to, in their code.
The main use case was to name the assume role session in AWS:
provider "aws" {
assume_role {
role_arn = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"
session_name = "${var.atlantis_user}-${var.atlantis_repo_owner}-${var.atlantis_repo_name}-${var.atlantis_pull_num}"
}
}
This is longer possible in 0.12.
If projects are configured using an atlantis.yaml with a specific
project name, include that in the output for comments. This is useful
because often the project names are better identifiers than the
directory and workspace names and also because some projects use the
same dir and workspace so the only way to differentiate them is via
their names.
Fixes#353
Fixes#290. In Bitbucket Server, the repo owner name can have spaces.
This causes errors when running terraform plan -out path with spaces so
we need to quote it: terraform plan -out "path with spaces".
GitLab allows repos to be nested under multiple subgroups,
for example owner/group/subgroup/subsubgroup/repo vs. owner/repo. This
change enables that functionality.
