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)
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.
- 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.
Previously, we were just logging when an error happened early in our
comment processing code. However it's possible for us to write comments
on error even at this early stage which will make for a better user
experience.
Fixes#398
