* add a pending status for apply when running plan command
* fix status updater logic, we should only update the status after we check if the PR is mergeable like the doc next to it says
* do not dismiss the PR if the only our "atlantis/apply" status is pending/failing
* fix logic and tests
* linting
* Improve github pull request call retries
Retry with fixed 1 second backoff up to 3 retries was added by #1131 to
address #1019, but the issue continued to show up (#1453).
Increase max attempts to 5 and use exponential backoff for a maximum
total retry time of (2^n - n - 1) seconds, which is roughly 30 seconds
for current max attempts n = 5.
Also move the sleep to the top of the loop so that we never sleep
without sending the request again on the last iteration.
* Fix style with gofmt -s
This is two changes:
Replacing all usages of SimpleLogger with it's interface SimpleLogging which makes it easier to swap out loggers going forward
Nukes SimpleLogger in favor of StructuredLogger which allows us to better analyze logs in our log management system we choose.
These calls have been 404'ing lately, likely due to eventual consistency
issues on GitHub's side where they send the PR created webhook but it's
not yet available on their API.
To work around this, we will retry up to 3 times with a 1s delay.
- 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
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.
This is needed so we can set different commit statuses for plan and
apply phases.
Also, append os env variables to git commands during cloning. This fixed
a bug when running tests where I got an error because git couldn't expand
'~' from its git config to my home directory because the HOME env var
wasn't set.
For repos with certain merge methods disabled (such as 'merge'), simply
hitting the GitHub `/merge` endpoint is not sufficient. Instead, we need
to check which methods are actually available, then use the appropriate
method.
With this change it will:
1. Default to 'merge' if enabled
2. Use 'rebase' if 'merge' is disabled and rebase is enabled
3. Use 'squash' if 'merge' is disabled
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.
Implement the change from the previous commit for GitLab and Bitbucket
Server/Cloud. Test the change for GitHub.
If a file is moved, we want to run plan in the directory it is moved to
*and* the directory it was moved from.
- Need to use the mergeable_state field in GitHub to know if a pull
request is mergeable.
- Add tests.
- Since we updated our vendored go-github library, fix how we were
creating webhooks in testdrive.
Introduce new `mergeable` requirement, in similar vein to the `approved`
requirement. Ran `make go-generate` to update mocks accordingly.
This addresses issue #43.
Adds close and (re)open <details> tag in between the split portions to
ensure the markup is correct across multiple comments. This isn't the prettiest, but a close result, under the assumption continued-comments are in 99% within a terraform output anyway...
