v0.7.2

v0.7.2

Description

Small release containing an important security fix and some bugfixes.

Features

None

Bugfixes

• Atlantis would post its Git credentials as pull request comment and in logs if the git clone failed. (Fixes #615)
• Atlantis would comment the same output twice during errors of custom run steps. (Fixes #519)
• atlantis testdrive had unreadable output on solarized terminals. (Fixes #575)

Backwards Incompatibilities / Notes:

None

Docker

runatlantis/atlantis:v0.7.2

Diff v0.7.1..v0.7.2

v0.7.1...v0.7.2

v0.7.1

v0.7.1

Description

Small bugfix release to fix an issue when using --checkout-strategy=merge.

Features

• PROJECT_NAME is now available as an environment variable to custom run steps. (#578)

Bugfixes

• Fix deleting unapplied plans when --checkout-strategy=merge is used. (Fixes #582)

Backwards Incompatibilities / Notes:

None

Docker

runatlantis/atlantis:v0.7.1

Diff v0.7.0..v0.7.1

v0.7.0...v0.7.1

v0.7.0

Description

This release implements Server-Side Repo Config which allows users to write
atlantis.yaml-style config on the server rather than in individual repos.
The Server Side config also allow Atlantis operators to control what individual
repos can do in their atlantis.yaml files. Read docs for more details.

Features

• Server-Side Repo Config. Read docs
  and use cases for full details. (#47)
  • New flag atlantis server flag --repo-config for specifying the
    repo config file .
  • New flag --repo-config-json for specifying the repo config as a JSON string
    instead of having to write a config file to disk.
  • All repos can now create atlantis.yaml files to configure their projects,
    however by default, those files can't create custom workflows or set Apply
    Requirements.
• New version 3 of atlantis.yaml fixes a small issue with how we were parsing
  custom run steps. Previously we were doing additional parsing which caused some
  users to have to add extra escaping to their commands. Now this is no longer
  required. See the Backwards Compatibility section for more details.

Bugfixes

• Fix bug where running atlantis apply to apply all outstanding plans wouldn't work if
  you had more than one project defined in the exact same directory and workspace. (Fixes #365)

Backwards Incompatibilities / Notes:

• The server-side config changes are fully backwards compatible. The biggest
  difference is that all repos can now create atlantis.yaml files, but without
  being able to create custom workflows or set apply requirements. This will
  allow users to configure their projects, workspaces and terraform versions
  at a repo level without enabling those repos to run custom code or circumvent
  apply requirements set server-side.

• atlantis.yaml has a new version 3. If you continue to use version 2, you
  will experience no changes. If you want to upgrade to version 3, then
  if you're not using any custom run steps in your workflows you can upgrade
  the version number without additional changes.

  If you are using run steps, check our upgrade guide
  to see if you need to make any changes before upgrading.

• Flags --require-approval, --require-mergeable and --allow-repo-config are
  deprecated in favour of creating a server-side repo config file that applies
  the same configuration. If you run atlantis server with those flags, a
  deprecation warning will be printed telling you what server-side config is
  recommended instead.

• If you have projects configured with the same directory and workspace (which means
  you're probably using the -backend-config flag) and their names contain /'s,
  then you'll have to re-run atlantis plan after upgrading if you had any unapplied plans.

  An example of what config would mean you need to re-plan:

  projects:
  - name: name/with/slashes
    dir: samedir
    workflow: a
  - name: another/with/slashes
    dir: samedir
    workflow: b
  a:
     plan:
       steps:
       - run: rm -rf .terraform
       - init:
           extra_args: [-backend-config=staging.backend.tfvars]
       - plan
  b:
     plan:
       steps:
       - run: rm -rf .terraform
       - init:
           extra_args: [-backend-config=staging.backend.tfvars]
       - plan

Docker

runatlantis/atlantis:v0.7.0

Diff v0.6.0..v0.7.0

v0.6.0...v0.7.0

v0.7.0-alpha1

⚠️ Alpha Release ⚠️ for testing server-side config.

v0.6.0

Description

This release introduces a new flag --default-tf-version=<version> that allows users
to set the version of Terraform that Atlantis defaults to. Atlantis will automatically
download that version on startup so users don't need to build their own custom
Docker images.

Atlantis will also now automatically download any Terraform version specified in
atlantis.yaml:

version: 2
projects:
- dir: .
  terraform_version: v0.12.0-beta1 # Will be downloaded automatically.

Features

• New flag: --default-tf-version=<version> will cause Atlantis to automatically download
  and use that version of Terraform by default. Atlantis will also automatically
  download terraform versions specified in atlantis.yaml via the terraform_version
  config key. (#538)
• New status check names mean that the Atlantis checks will appear together (at least on GitHub).
  (#545)
• Upgrade base Docker image to use Alpine 3.9. Alpine 3.9 mitigates
  CVE-2018-19486. (#541)

Bugfixes

None

Backwards Incompatibilities / Notes:

• Our Docker image runatlantis/atlantis has Terraform v0.11.13 now. If you
  use the new flag --default-tf-version=<desired version> then you won't
  be affected by this change (nor for subsequent version upgrades).

• The Atlantis status checks have been renamed from what they looked like in v0.5.*.
  Previously the names were: plan/atlantis and apply/atlantis. Now the
  names are atlantis/plan and atlantis/apply.

  This change will only affect you if you're requiring those status checks to pass via a setting in
  your Git host (ex. via GitHub protected branches). If so, you'll need to change
  your settings to require the new names to pass and un-require the old names.

  If you were on a version lower than v0.5.* then read the backwards compatiblity
  notes for release 0.5.0.

  NOTE from the maintainer: I take backwards compatibility seriously and I
  apologize that the status checks are changing again so soon after the 0.5 release
  also changed them. I know that if you have many repos and require the checks
  to pass that it is a large task to change them all again.

  In this case, I decided that the tradeoff was worth it because the
  0.5 release has only been out for a couple of weeks so hopefully not everyone
  has upgraded to it. The new check names makes them a lot easier to read
  (at least on GitHub) because they appear next to each other now due to
  alphabetical sorting. In this case I felt like it was better to get this change
  done as soon as possible rather than having this annoying UX issue stay around
  forever.

Docker

runatlantis/atlantis:v0.6.0

Diff v0.5.1..v0.6.0

v0.5.1...v0.6.0

v0.5.1

v0.5.1

Description

This is a bugfix release to fix a bug where Atlantis was replying to comments
that weren't directed to it.

Diff: v0.5.0...v0.5.1

Features

• On Bitbucket Cloud and Server, Atlantis now responds if it's invoked with the
  username it's running under, ex. @my-bb-atlantis-user. This is the same
  functionality as GitHub and GitLab. (#534)

Bugfixes

• Atlantis ignore comments that aren't addressed to it. (Fixes #533)

Backwards Incompatibilities / Notes:

• On Bitbucket Cloud and Server, Atlantis now responds if it's invoked with the
  username it's running under, ex. @my-bb-atlantis-user. This is the same
  functionality as GitHub and GitLab.

Docker

runatlantis/atlantis:v0.5.1

v0.5.0

v0.5.0

Description

This release has two big features: New Status Checks and Terraform Enterprise
Integration.

New Status Checks:

The new status checks split the old status check into plan and apply phases.
Each check now tracks the status of each project modified in the pull request.
For example if two projects are modified, the plan check might read:

2/2 projects planned successfully.

And the apply check might read:

0/2 projects applied successfully.

Users can now use their Git host's settings to require these checks pass
before a pull request is merged and be confident that all changes have been
applied (for example).

Terraform Enterprise Integration:

Atlantis now integrates with the Terraform Enterprise (TFE)
via the remote backend.
Atlantis will run terraform commands as usual, however those commands will
actually be executed remotely in Terraform Enterprise.

Using Atlantis with Terraform Enterprise gives you access to TFE features like:

• Real-time streaming output
• Ability to cancel in-progress commands
• Secret variables
• Sentinel
  Without having to change your pull request workflow.

Diff: v0.4.15...v0.5.0

Features

• Split single status check into one for plan and one for apply (see above).
• Support using Atlantis with Terraform Enterprise via
  remote operations (see above).
• Add USER_NAME environment variable for custom steps to use. (#489)
• Support Bitbucket Cloud's upcoming API deprecations. (#502)
• Support Bitbucket Server hosted at a basepath, ex. bitbucket.mycompany.com/pathprefix (Fixes #508)

Bugfixes

• Allow Bitbucket Server diagnostics checks. (Fixes #474)
• Fix automerge for Bitbucket Server. (Fixes #479)
• Run terraform init with -upgrade. (Fixes #443)
• If a pull request is deleted in Bitbucket Server, delete locks. (Fixes #498)
• Support directories with spaces, ex atlantis plan -d 'dir with spaces'. (Fixes #423)
• Ignore Terragrunt cache directories that were causing duplicate applies. (Fixes #487)
• Fix atlantis testdrive for latest version of ngrok.

Backwards Incompatibilities / Notes:

• New Status Checks - If you have settings in your Git host that require the Atlantis commit status
  check to be in a certain condition, you will need to modify that setting as follows:

  Previously, Atlantis set a single check with the name Atlantis. Now there are
  two checks with the names plan/atlantis and apply/atlantis. If you had
  previously required the Atlantis check to pass, you should now require both
  the plan/atlantis and apply/atlantis checks to pass.

  The behaviour has also changed. Previously, the single Atlantis check
  would represent the status of the last
  run command. For example, if I ran atlantis plan and it failed, the check
  would be in a Failed state. If I ran atlantis apply -p project1 and it succeeded,
  then the check would be in a Success state, regardless of the status of other projects
  in the pull request.

  Now, each check represents the plan/apply status of all projects modified in
  the pull request. For example, say I open up a pull request that modifies
  two projects, one in directory proj1 and the other in proj2. If autoplanning
  is enabled, and both plans succeed, then there will be a single status check:

  • plan/atlantis - 2/2 projects planned successfully (success)

  If I run atlantis apply -d proj1, then Atlantis will set a pending apply check:

  • plan/atlantis - 2/2 projects planned successfully (success)
  • apply/atlantis - 1/2 projects applied successfully (pending)

  If I apply the final project with atlantis apply -d proj2, then my checks
  will look like:

  • plan/atlantis - 2/2 projects planned successfully (success)
  • apply/atlantis - 2/2 projects applied successfully (success)

• terraform init is now run with -upgrade=true. Previously, it used Terraform's
  default setting which was false.

  This means that terraform will always update to the latest version of plugins
  and modules. For example, if you're using a module source of

  source = "git::https://example.com/vpc.git?ref=master"

  then terraform init will now always use the version on master whereas
  previously, if you had already run atlantis plan before master was updated,
  a new atlantis plan wouldn't pull the latest changes and would just use
  the cached version.

  This is unlikely to cause any issues because most users already expected Atlantis
  to use the most up-to-date version of modules/plugins within the set constraints.

Docker

runatlantis/atlantis:v0.5.0

v0.4.15

Description

This is a bugfix release containing an important fix to how Atlantis executes Terraform. A
bug was introduced in v0.4.14 that causes Atlantis to hang indefinitely when
executing Terraform when there is a lot of output from Terraform.

In addition, there's a fix to automerge when you require rebasing or commit
squashing in GitHub and a fix for the mergeability check if you're requiring
the Atlantis status to pass in GitHub.

Diff: v0.4.14...v0.4.15

Features

None – this is a bugfix release.

Bugfixes

• Atlantis hangs on large plans. (Fixes #452)
• Automerge now works on GitHub if you require a rebase or squash merge. (#466)
• Automerge now works on Bitbucket if previously you were getting XSRF errors. (Fixes #465)
• Requiring mergeable now works on GitHub if you are also requiring the Atlantis status to pass before merging. (Fixes #453)

Backwards Incompatibilities / Notes:

None

Docker

runatlantis/atlantis:v0.4.15

v0.4.14

⚠️WARNING⚠️ This release introduced a critical bug in how Terraform executes that causes Atlantis to hang on large infrastructures. Use v0.4.15 instead.

Description

This release contains two big new features: Automerge and Checkout Strategy.

Automerge is a much asked for feature that allows Atlantis to automatically
merge your pull requests if all plans have been applied successfully.
It can be enabled via the --automerge flag, or via an atlantis.yaml setting:

version: 2
automerge: true
projects:
- ...

Checkout Strategy allows you to choose if Atlantis checks out the exact branch
from the pull request or what the destination branch will look like once the pull
request is merged. You can choose your checkout strategy via the --checkout-strategy
flag which supports branch (the default) or merge.

Diff: v0.4.13...v0.4.14

Features

• Can now be configured to automatically merge pull requests after all plans have
  been applied. See https://www.runatlantis.io/docs/automerging.html. (Fixes #186)
• New --checkout-strategy flag which supports checking out the code as it will
  look once the pull request was merged. Previously we only supported checking out
  the pull request branch which might be out of date with the destination branch
  and so cause Terraform to delete resources that have already been applied.
  See https://www.runatlantis.io/docs/checkout-strategy.html. (Fixes #35
• Support Terraform 0.12 by version detection and then changing how Atlantis runs
  its Terraform commands. (#419)
• New --tfe-token flag to support using Terraform Enterprise's Free Remote State Storage. (#419)

Bugfixes

• Run plan in directory when file is moved. (Fixes #413)
• Fix bug where when Terraform crashed, Atlantis would hang indefinitely. (#421)

Backwards Incompatibilities / Notes:

None

Docker

runatlantis/atlantis:v0.4.14

v0.4.13

Description

This release is focused on quick-wins, bugfixes and one new feature that allows
users to require pull requests be "mergeable", before allowing for atlantis apply.

The mergeable apply requirement is very useful for GitHub users where it allows
them to require pull requests be approved by specific users or require certain
status checks to pass. See https://www.runatlantis.io/docs/apply-requirements.html#mergeable for
more information.

Diff: v0.4.12...v0.4.13

Features

• Introduce a new (optional) mergeable apply requirement that requires pull requests to be mergeable prior to allowing apply to run. (Fixes #43)

• If users have workspaces configured for a directory via an atlantis.yaml file, only allow
  commands to be run on those workspaces. All commands attempted to be run on different workspaces will error out.

  For example, if I have an atlantis.yaml file:

  version: 2
  projects:
  - dir: mydir
    workspace: default
  - dir: mydir
    workspace: staging

  Then I can run atlantis apply -d mydir -w default and atlantis apply -d mydir -w staging
  but I will receive an error if I run atlantis apply -d mydir -w somethingelse.

• If users are setting the name key for their projects in atlantis.yaml, then
  include the project name in the comment output so it's easier to identify which
  plan/apply output is for which project. (Fixes #353)

• Bump the Terraform version in the Docker image to 0.11.11.

• Tweak logging to add timezone to the timestamp and make the output more readable. (#402)

• Warn users if running atlantis apply -- -target=myresource because -target can
  only be specified during atlantis plan. (Fixes #399)

Bugfixes

• If terraform plan returns an error, print the error to the pull request. (#381)
• Split Bitbucket Server comments into multiple comments if over the max size. (Fixes #280)
• Fix issue where if users specified --gitlab-hostname without a scheme then Atlantis wouldn't parse the URL correctly. (#377)
• Give better error message if GitLab users are commenting on commits instead of a merge request. (Fixes #150, #390)
• If an error occurs early in request processing, comment that error back on the pull request.
  Previously, we were commenting back on errors but not for errors very early in the processing. (Fixes #398)

Backwards Incompatibilities / Notes:

• The version of Terraform installed in the runatlantis/atlantis Docker image
  is now 0.11.11. Previously it was 0.11.10.

• If you are a) using an atlantis.yaml file and b) defining Terraform workspaces
  and c) running plan and apply against workspaces that were not defined in the
  atlantis.yaml file, then this no longer works.

  You will now need to define all the workspaces in the atlantis.yaml file.
  For example, say you had the following config:

  version: 2
  projects:
  - dir: mydir
    workspace: production

  And you used to run:

  atlantis plan -d mydir -w anotherworkspace
  atlantis apply -d mydir -w anotherworkspace
  

  For this to work now, you need to add the anotherworkspace workspace to your
  atlantis.yaml file:

  version: 2
  projects:
  - dir: mydir
    workspace: production
  - dir: mydir
    workspace: anotherworkspace

Docker

runatlantis/atlantis:v0.4.13