#atlantis (2020-09)
Discuss the Atlantis (<http://runatlantis.io | runatlantis.io>) |
**Archive: ** https://archive.sweetops.com/atlantis/
2020-09-01
2020-09-02
2020-09-07
2020-09-08
2020-09-11

Atlantis people

I seek a guru among you. I have a few questions… First is there a way with - env
in a custom workflow to ingest ENVIRONMENT VARIABLES form the container into the run command? I’m having issues with this not work.
https://www.runatlantis.io/docs/custom-workflows.html#reference
I saw the below in their documentation, is it possible to extend this environment variables? Am I doing something wrong with the workflow below?
Notes
• run
steps are executed with the following environment variables:
• …

test_workflow:
plan:
steps:
- run: rm -rf .terragrunt*
- run: helm version
- env:
name: CHARTMUSEUM_PASSWORD
value: ${CHARTMUSEUM_PASSWORD}
- run: helm repo add %REPONAME% %REPOURL% --username user --password $CHARTMUSEUM_PASSWORD
- env:
name: TERRAGRUNT_TFPATH
command: 'echo "terraform${ATLANTIS_TERRAFORM_VERSION}"'
- run: terragrunt plan-all -no-color --terragrunt-parallelism 4 | grep -v 'terragrunt'

Secondly, how is the experience with Terragrunt & Atlantis?

You can use env vars with Atlantis ayte

I’m finding the $PLANFILE to not work well when autoplan is running a plan-all
against multiple dirs

Experience with Terragrunt + Atlantis is working well for us.

Am I doing something wrong above @joshmyers

@Callum Robertson Nope, that workflow is broken, don’t use $ACTION-all commands. They aren’t safe IMO

the - run: helm repo add %REPONAME% %REPOURL% --username user --password $CHARTMUSEUM_PASSWORD
doesn’t evaluate the environment variable, takes it as literal string

yeah… it’s a bit painful…

Seriously considering moving to Workspaces with the DependsOn between modules now

Sounds like you are talking about different problems there….

Have you looked at the docs? https://www.runatlantis.io/docs/custom-workflows.html#use-cases Specifically the -env
directive
Atlantis: Terraform Pull Request Automation

yes I have, can I use the value
or the command
variants of the - env
in subsequent -run
steps?

e.g.
- env:
name: TEST
value: test_value
- run: echo $TEST

I believe so yes

As a user of atlantis, I want to be able to specify a custom list of environment variables and use the default init, plan, apply steps. This allows me to not write custom commands when running terr…
2020-09-13


This should really be documented better
2020-09-15

Hi guys is there a way to see the running log of an atlantis apply, or cancel it? we seem to have a stuck plan

Atlantis: Terraform Pull Request Automation

if I unlock it will cancel the current running apply?

In my case, yes, github stop actions for this job

I see, I will give it a go then thanks

I think you can also comment atlantis unlock


it would be really nice to get more logs from atlantis

True, even with debug there is not a lot to read.

thanks for your help - maybe there are good alternatives with this functionality

No there is currently no way to stream the output from the plan/apply to logs

Trick is to make sure what Atlantis is running, is exactly what you can run locally.

right, makes sense - we were having problems because during the apply it was trying to wget
the EKS private API

which the atlantis machine did not have permission to do

Do you know if Atlantis is still being actively maintained? (looks to be from the github repo)

I think Luke has mostly stopped with new features but maybe helping with PRs (since joining Hashicorp himself) but community is mostly doing bug fixes / any new features

There was talk about an API endpoint to run plan/apply that sounded like a nice addition, not sure how far that got.


right, I guess he now works for his own competition

perhaps he will hand over ownership if someone is willing ..

Well, they hired him to work on a similar product, so pretty sure they aren’t too keen on him working on an open source alternative



ah cool

Padarn Wilson ?

You look like another Padarn I know from a another Slack

I am another Padarn you know from slack haha

small world

?

+

2020-09-16
2020-09-21

Quick question, is this approach correct. One github repo with production and staging terragrunt manifests Separated atlantis service for stage and prod one atlantis.yaml for both with different workflows

There are lots of workable approaches, but I think using a single atlantis service that can assume roles is the more standard approach

One service is not acceptable , legal stuff.

That makes things a bit harder, but I think your approach makes sense with that requirement

Right now, two separated services deployed. Prod service complains
parsing atlantis.yaml: workflow "stage" is not defined anywhere
so I think I need to add dummy workflow for stage on production service.

I run multiple atlantis in different accounts

you will get that error no matter what

I use this fork

Terraform Pull Request Automation. Contribute to sonatype/atlantis development by creating an account on GitHub.

look at the code changes, there is one specifically so that the atlantis server only parse atlantis-prod.yaml, atlantis-stage.yaml and does not try to run plan

that way you just get the error you mention only

I fixe the issue by adding to production atlantis service dummy stage workflow with true on plan and apply like this
repo-config-json = {
repos = [
{
id = "/.*/",
allowed_overrides = ["apply_requirements", "workflow"],
allow_custom_workflows = true
apply_requirements = ["mergeable"]
}
]
workflows = {
prod = {
plan = {
steps = [
{
run = "terragrunt plan -no-color -out $PLANFILE 2> $PLANFILE.stderr || cat $PLANFILE.stderr"
}
]
},
apply = {
steps = [
{
run = "terragrunt apply"
}
]
}
},
stage = {
plan = {
steps = [
{
run = "true"
}
]
},
apply = {
steps = [
{
run = "true"
}
]
}
}
}
}

anyone know why they don’t allow to set yaml file per instance?

nice hack!!! that is cool, I did not bother to fix the errors since they added an option to delete old comments so the error shows for very little time and then it goes away

I have been following that request a lot and the answers about multiserver have been very simplistic in my opinion and somehow the devs think is more complicated that what you did or what I did

things like “smarter way” have been mention in the PRs with no explanation of the idea behind

at the same time the Dev that maintains Atlantis works in hashicorp so there might be conflicts of interests

it is funny that this kind of features are not added and there is like ~350 forks of atlantis

it’s not working , but I’ve decided to apply patch to original source it’s just
diff --git a/server/events/yaml/parser_validator.go b/server/events/yaml/parser_validator.go
index 0e2bd84a..048c7efd 100644
--- a/server/events/yaml/parser_validator.go
+++ b/server/events/yaml/parser_validator.go
@@ -17,7 +17,16 @@ import (
)
// AtlantisYAMLFilename is the name of the config file for each repo.
-const AtlantisYAMLFilename = "atlantis.yaml"
+var AtlantisYAMLFilename string
+
+// Simplest hack to allow overriding "atlantis.yaml" to another name
+func init() {
+ AtlantisYAMLFilename = os.Getenv("ATLANTIS_YAML_FILENAME")
+ if AtlantisYAMLFilename == "" {
+ AtlantisYAMLFilename = "atlantis.yaml"
+ }
+}
+

Finally without patch, one instance of Atlantis for 3 account
repo-config-json = {
repos = [
{
id = "/.*/",
allowed_overrides = ["apply_requirements", "workflow"],
allow_custom_workflows = true
apply_requirements = ["mergeable"]
}
]
workflows = {
cicd = {
plan = {
steps = [
{
run = "terragrunt plan -no-color -out $PLANFILE 2> $PLANFILE.stderr || cat $PLANFILE.stderr"
}
]
},
apply = {
steps = [
{
run = "terragrunt apply"
}
]
}
},
prod = {
plan = {
steps = [
{
"env" : {
"name" : "TERRAGRUNT_IAM_ROLE",
"value" : "${local.production_role}"
}
},
{
run = "terragrunt plan -no-color -out $PLANFILE 2> $PLANFILE.stderr || cat $PLANFILE.stderr"
}
]
},
apply = {
steps = [
{
"env" : {
"name" : "TERRAGRUNT_IAM_ROLE",
"value" : "${local.production_role}"
}
},
{
run = "terragrunt apply"
}
]
}
},
stage = {
plan = {
steps = [
{
"env" : {
"name" : "TERRAGRUNT_IAM_ROLE",
"value" : "${local.staging_role}"
}
},
{
run = "terragrunt plan -no-color -out $PLANFILE 2> $PLANFILE.stderr || cat $PLANFILE.stderr"
}
]
},
apply = {
steps = [
{
"env" : {
"name" : "TERRAGRUNT_IAM_ROLE",
"value" : "${local.staging_role}"
}
},
{
run = "terragrunt apply"
}
]
}
}
}
}
}

why the patch did not work?

Atlantis confused developers, one instance commented Ran plan for 0 projects
and the other commented with proper plan

yes that is a side effect

so now you get one plan that works and one that does not in your comments?

now I have one instance of Atlantis which use switch role to access stage/prod env

we have separated CI/CD account in which Atlantis is deployed, one atlantis yaml with 3 workflows, basically Atlantis operates on CICD/stage/prod account

ahhhh i c ok
2020-09-22
2020-09-23
2020-09-24

Anyone have experience setting up atlantis to run ansible ?

Is that even possible ?

you can run whatever you want in a shell script with a custom run command

but you need the software installed etc in case you are running on a container

Got it ! So I was thinking same, writing a custom shell wrapper
2020-09-25

Ya, it’s no different than running #terragrunt - so check out one of those guides and it will probably help

2020-09-28
2020-09-29
2020-09-30

Go an Vote so we can have the gh-team whitelist solution form cloudposse in atlantis main repo https://github.com/runatlantis/atlantis/pull/1206
Add the ability to specify a whitelist of GitHub teams and Atlantis commands that those teams can execute. The idea behind this is that an Atlantis operator can pass a parameter to the Atlantis ser…

dang! still no update on this, huh? 34 too!
Add the ability to specify a whitelist of GitHub teams and Atlantis commands that those teams can execute. The idea behind this is that an Atlantis operator can pass a parameter to the Atlantis ser…

yep, still waiting