hootsuite / atlantis Goto Github PK

When receiving a SIGTERM Atlantis server should shutdown cleanly.

• So currently we need s3 to store plans. We need to be able to store plans on the local filesystem.

Logging guielines

• logging is going to be used for 2 purposes
  • debugging why someone's repo is erroring. So for this use case people will want to know how atlantis is interacting with their repo
  • debugging why atlantis is erroring. For this use case we'll need to make sure we're actually logging what atlantis is doing (so for example real paths)
• log what happened, not what is about to happen*. This will reduce the amount of log statements

getting modified files
found 10 modified files
# or
getting modified files
error getting modified files

Do

found 10 modified files
#or
error getting modified files

• *except for when the following log messages wouldn't make sense unless we knew their context. For example, when running plan in multiple directories, stating that "running plan in {dir}" is needed to understand the context of the following logs
• for commands executed, we should always log the command and directory. If there is an error, we should include the output of the command on the comment back to github but not in our error logs since that would make them too noisy

Guidelines

• any output from an executable will be in code blocks
  • ex. terraform output
• for errors, we try to provide a human-readable reason which will be in regular text, and then the actual output can be in a code block
• we should distinguish errors and failures. Errors are unexpected and so we won't be able to have a template for each of them. Failures should be expected, like a pull request not being approved, or no files being modified. Failures should have a simple comment without any detailed error text.

Examples below.

Would be awesome to have this support GitLab

Installation Options

• install webhook on individual repositories
• install webhook on organization
• install as oauth app
• install as Github App

Can also choose between listening for comments mentioning an @atlantis user or just the string "atlantis"

Webhooks require a two step installation: create a user and then add the webhook to the repo
OAuth could be a one-step solution but we'd need to support oauth flow
I don't think Github Apps will work for Github Enterprise. CircleCI's instructions ask people to add it as an OAuth App. I haven't done a ton of research into this. Apps are nice because they automatically get a bot user associated with them, but I think it's probably over complicated for what we need.

So I think we should recommend adding as a git hook on the organization and also setting up an Atlantis user.

We could use the mentions API but I think we should still use webhooks so we can do things like auto-planning in the future (before atlantis is mentioned). We can also support both @atlantis and atlantis.

GitHub's api has it like this.

"repo": {
        "id": 35129377,
        "name": "public-repo",
        "full_name": "baxterthehacker/public-repo",

The only place we need it separately is when we pass it into github client. At those locations we can just split on / but everywhere else is simpler

• Add atlantis apply to e2e tests
• Add more e2e tests for all types of projects we support

Investigate calls to start session and assume role throughout the codebase
and ensure they will work past any timeouts and that we're also not spamming
aws sessions

• Finish all the OSS steps for Hootsuite (Legal etc.)
• Switch hootsuite/atlantis-example from private to public
• Update atlantis to point to hootsuite/atlantis-example project instead of airauth/example
• Update atlantis bootstrap mode to point the correct documentation
• Update logo on embedded atlantis website

After Release:

• Add CLA bot
• Create 0.1 release

This issue can be reproduced by commenting plan staging and plan production in quick succession.
Will error out with something like

error running plan: 2 error(s) occurred:

* file: open /private/tmp/atlantis/lkysow/atlantis-terraform-test/10/.terraform/modules/717f47b625fc0873bb7bd027de734d00/templates/userdata.tpl: no such file or directory in:

${coalesce(var.user_data_template, file("${path.module}/templates/userdata.tpl"))}
* file: open /private/tmp/atlantis/lkysow/atlantis-terraform-test/10/.terraform/modules/717f47b625fc0873bb7bd027de734d00/templates/userdata.tpl: no such file or directory in:

${coalesce(var.user_data_template, file("${path.module}/templates/userdata.tpl"))}

because we clean the workspace when we get a new event

Right now we're sending the Accept: application/vnd.github.black-cat-preview+json header because our version of github enterprise hasn't been updated to the latest. This will cause approval checking to fail on github.com.

We should try without the header and if it fails, send it with the header. Or look into if there's a way to know which version of GitHub is being run.

Would be awesome to have this support BitBucket

type Project struct {
	Repo Repo
	// Path to project root in the repo.
	// If "/" then project is at root
	// All paths must end with "/"
	Path string 
}

A project is where you'd run terraform plan/apply from. We have a Path because some repos may have multiple terraform projects. A project may have multiple environments or just the default environment. I don't think we need to have that data in the struct though.

type ProjectLock struct {
	Project Project
	Pull Pull
        Environment string
	Timestamp time.Time
}

I also think we should call this a ProjectLock because we're not locking a Run, the ProjectLock is created as a result of a Run.

func (p Project) Key() string {
    return fmt.Sprintf("%s%s", p.Repo.FullName, p.Path)
}

The Key() is used for looking up a ProjectLock in the database. When a plan command is run, we look up existing locks for that Project with the key.

Should be able to click in to list of locks and see more detail.
Should also have a DELETE button that makes a DELETE request to
the backend and deletes the lock

Currently, atlantis ignores certain folders such as _modules/ and modules/ but we want to extend this to ignore any folder that has .atlantisignore file or something along those lines. https://github.com/hootsuite/atlantis/blob/master/server/plan_executor.go#L196

I saw Mishra's ConfigMgmtCamp talk in Portland today, and this project is exactly what we'd been looking for.

A few questions as to running this in production:

1. The Production-Ready section makes no mention of SSL, but I assume there would be no issue hosting this behind an SSL-enabled proxy. Would that work?
2. Could Atlantis be hosted on multiple hosts behind a single load balancer? From my brief look at the code, it appears I'd have to work out a way to share the data dir that is used for the locking bolt database. Anything I'm missing?

Can then use github.ValidatePayload method.
Will be optional.

How we'll support multiple terraform versions

• detect terraform version by running terraform version #todo
• detect project root
• check terraform_version
• if >= 0.9
  run terraform init
• if >= 0.9 AND environment is specified
  run terraform env select {env}, may also need to create it with new
• run pre_plan commands
• run plan
  • if env/{env}.tfvars add -var-file=env/{env}.tfvars automatically
  • append all options that were specified in atlantis.yaml

Changes:

• atlantis.yaml
  • get rid of stash_path
  • add terraform_args that lets users add args to all terraform commands, ex. -no-color. allow arguments to: plan, apply, init
• change code flow to support the above ^^

Current Key

The object is the planfile itself and the key is determined as follows where prefix is set to /plans

• 1: path: root, env: none
  • {prefix}/{owner}/{repo}/{owner}_{repo}_{pullNum}.tfplan
• 2: path: root, env: env
  • {prefix}/{owner}/{repo}/{owner}_{repo}_{pullNum}.tfplan.{env}
• 3: path: parent/child, env: none
  • {prefix}/{owner}/{repo}/{owner}_{repo}_{pullNum}_parent_child.tfplan
• 4: path: parent/child, env: env
  • {prefix}/{owner}/{repo}/{owner}_{repo}_{pullNum}_parent_child.tfplan.{env}

Actions

The key is used as follows

• apply {env} command comes in
• pull down all plans with prefix {prefix}/{owner}/{repo}/{owner}_{repo}_{pullNum}
• look at suffix and see if it has the correct env. Since no env is "" this will also return true for case 1 and 3.
• download the matching plans into {scratchDir}/{owner}_{repo}_{pullNum}{_any sub dirs}.tfplan{.optional env}
• parse the name and pull out any sub dirs
• move plans to where the repo is cloned and into their correct sub dirs: {scratchDir}/{owner}/{repo}/{pullNum}/{subdirs}
• cd into each sub dir and run apply with the -tfvars=env/{env}.tfvars if needed

Needed Functionality

1. Look up plans by a) repo and pull, b) repo, pull and env so we can run apply and apply {env}
2. Know subdir and env for each plan so we can put it in the correct location and apply the right terraform env {env} or -tfvars env/{env}.tfvars

Changes

• Storing information in the key format and then parsing it back out is a bit of hack when there is S3 Metadata. I think we should use that to store repo, pull, env and subDirs. Then our key structure can be changed separately to the file metadata.
• Then we can could change the keys but we'd still need to keep them unique and still need to be able to pull based on prefix. Maybe {prefix}/{owner}/{repo}/{pullNum}/{parent}/{child}/{env}.tfplan?

Failed to render template, this is a bug: template: :3:2: executing "" at <.Error>: can't evaluate field Error in type struct { Command string; Output string }

This more closely matches what the name for what is happening.
Can add a hidden cli option to support the old /hooks endpoint

Add post_apply command. This functionality would be super helpful in terms of performing tests after deploying infrastructure.

See https://github.com/rauchg/slackin

Also add a badge to our readme

Right now we're writing code like

func (r *RequestParser) extractPullData(pull *github.PullRequest, params *CommandContext) error {
	commit := pull.Head.SHA
	if commit == nil {
		return errors.New("key 'pull.head.sha' is null")
	}

but if pull or Head was nil this would panic. We just need to check these better.

Proposal

• place tests under package {package under test}_test to enforce testing the external interfaces
• if you need to test internally i.e. access non-exported stuff, call the file {file under test}_internal_test.go
• use the testing_util for easier-to-read assertions import . "github.com/hootsuite/atlantis/testing_util"
• don't try to describe the whole test with a camel case test function name. Instead use t.Log statements:

// don't do this
func TestLockingWhenThereIsAnExistingLockForNewEnv(t *testing.T) {
    ...

// do this
func TestLockingExisting(t *testing.T) {
    	t.Log("if there is an existing lock, lock should...")
        ...
       	t.Log("...succeed if the new project has a different path") {
             // optionally wrap in a block so it's easier to read
       }

Probably using govendor