By fixing nil pointer reference in 3428 we unveiled yet another bug now that the code is able to run further:
When an MR with no HeadPipeline exists its commits are set to skipped by default and thus create some mess when running "PullMergeable" (rendering the MR useless)
The bug was caught by the tests, however, in an attempt to make the build pass and unblock we create a patch to ignore that test.
In order to prevent further problems, this MR:
* Updates the test stack to run all plan/apply commands in the context
of "HeadLess" Pipelines
* Fixes the default of skipped pipeline to false (as it is better to
assume it is NOT skipped since that prevents the merge in most cases)
* Make all integratiion tests pass
References:
* Original MR: https://github.com/runatlantis/atlantis/pull/3428
* Tests Patch MR : https://github.com/runatlantis/atlantis/pull/3653
* Implement test for allow mergeable bypass apply with no branch protection checks
* Report true combined status if no branch protection required status checks
* Remove warning on feature flag utilization
In this particular example `mr.HeadPipeline.SHA` panics on a nil pointer dereference because HeadPipeline is empty.
This seems to be caused by the lack of permission to update the commit status.
```go
runtime.gopanic
runtime/panic.go:1038
runtime.panicmem
runtime/panic.go:221
runtime.sigpanic
runtime/signal_unix.go:735
github.com/runatlantis/atlantis/server/events/vcs.(*GitlabClient).PullIsMergeable
github.com/runatlantis/atlantis/server/events/vcs/gitlab_client.go:208
github.com/runatlantis/atlantis/server/events/vcs.(*ClientProxy).PullIsMergeable
github.com/runatlantis/atlantis/server/events/vcs/proxy.go:72
github.com/runatlantis/atlantis/server/events/vcs.(*pullReqStatusFetcher).FetchPullStatus
github.com/runatlantis/atlantis/server/events/vcs/pull_status_fetcher.go:28
github.com/runatlantis/atlantis/server/events.(*ApplyCommandRunner).Run
github.com/runatlantis/atlantis/server/events/apply_command_runner.go:105
github.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).RunCommentCommand
github.com/runatlantis/atlantis/server/events/command_runner.go:252
```
The least invasive solution is to simply use the commit-hash from pull and guess that the pipeline was "skipped" unless the HeadPipeline is there.
The outcome is:
When mr.HeadPipeline is present:
- use the commit hash and status from the HeadPipeline
When mr.HeadPipeline is NOT present:
- use the commit hash from pull request struct
- assume the pipeline was "skipped"
In cases where GitLab is configured to require a pipeline to pass, this results on a message saying the MR is not mergeable.
More info:
- https://github.com/runatlantis/atlantis/issues/1852
* mod: rename updateCommitStatus func
* feat: add PlannedNoChangesPlanStatus
* Add skipApplyNoChanges option to PlanCommandRunner
* Add skipApplyNoChanges option to ApplyCommandRunner
* Add --skip-apply-no-changes flag
* Fix typo
Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
* Rename --skip-apply-no-changes flag
* Refactor updateCommitStatus functions
* chore(docs): add detailed use case for the flag
* test: add plan_command_runner set apply status
* feat: set apply status to successful by default when result is 'No Changes'
---------
Co-authored-by: chroju <chroju@users.noreply.github.com>
Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
While using a PR from a fork and the "Github allow mergeable bypass apply" flag, the mergeable checks were run with the wrong owner in the request, leading to 404. By choosing the owner from the head repo data it should work both, for fork PRs and in-repo PRs.
Co-authored-by: Dylan Page <dylan.page@autodesk.com>
Problem
When `projects` are specified and `when_modified` is not specified via
the config file, changing `.terraform.lock.hcl` file won't trigger auto
plan. This is because the default `raw.WhenModified` does not include
`.terraform.lock.hcl`.
Note that when projects are auto detected, changing
`.terraform.lock.hcl` triggers auto plan. This is because the
`cmd.DefaultAutoplanFileList` includes `.terraform.lock.hcl`.
Solution
Include `.terraform.lock.hcl` to the default `raw.WhenModified`.
* Include information about imports in PlanSuccessStats
Terraform 1.5 introduced a feature to import existing resources into
state via code.
https://developer.hashicorp.com/terraform/language/import
When you run `terraform plan` with imports, the output includes information
about the imported resources, which breaks the current regex for parsing
plan changes.
This PR updates the regex to include the, optional, import information.
* Use the ?
Co-authored-by: Benjamin Ullian <5695343+bnu0@users.noreply.github.com>
---------
Co-authored-by: Will Richard <wrichard@seatgeek.com>
Co-authored-by: Benjamin Ullian <5695343+bnu0@users.noreply.github.com>
Co-authored-by: Dylan Page <dylan.page@autodesk.com>
* fix(deps): update module github.com/petergtz/pegomock/v3 to v4 in go.mod
* remove pegomock generate m option, which is not support after v4
* make regen-mocks
* replace pegomock v4 primitive eq/matchers
* convert pegomock v4 Eq/Any matchers
* remove custom models.Repo matcher
* pegomock v4 cannot use result method args
ref https://github.com/petergtz/pegomock/issues/123
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* whitespace fixes
* Only re-clone on upstream updates just before planning
When using the merge checkout strategy, we would peviously
re-clone on upstream updates on any call to Clone(), for example
when running workflow hooks or runing import commands.
If we had already ran a plan, and master was updated, this
would delete the plan and apply would not have anything to
apply.
Modified to only re-clone on upstream updates in doPlan()
* Apply suggestions from code review
---------
Co-authored-by: PePe Amengual <jose.amengual@gmail.com>
Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
* Capture stats in plan changes regexp
Signed-off-by: Leandro López (inkel) <leandro.lopez@grafana.com>
* Add PlanSuccessStats model to hold plan stats
This will be useful to pass down to the templates to include
additional information when formatting the messages emitted by Atlantis.
Signed-off-by: Leandro López (inkel) <leandro.lopez@grafana.com>
* Return stats for a PlanSuccess
Signed-off-by: Leandro López (inkel) <leandro.lopez@grafana.com>
* Add plan success stats to template data
Signed-off-by: Leandro López (inkel) <leandro.lopez@grafana.com>
* Refactor plan success template data creation
DRY. Also highlights a bug where the stats should be a field in
planSuccessData in order to be accessible from the templates.
Signed-off-by: Leandro López (inkel) <leandro.lopez@grafana.com>
* Move plan stats to planSuccessData struct
Signed-off-by: Leandro López (inkel) <leandro.lopez@grafana.com>
---------
Signed-off-by: Leandro López (inkel) <leandro.lopez@grafana.com>
Co-authored-by: PePe Amengual <jose.amengual@gmail.com>
Co-authored-by: nitrocode <7775707+nitrocode@users.noreply.github.com>
