Quickstart Basic Guide Fails on mu pipeline up

[mneil]

I'm receiving this error in cloudwatch

arn:aws:sts::324320755747:assumed-role/mu-pipeline-mu-ci-us-west-2/AWSCodeBuild-9264ba60-3463-48f6-9891-bad3e7cfab95 is not authorized to perform: cloudformation:CreateStack on resource: arn:aws:cloudformation:us-west-2:324320755747:stack/mu-repo-mu-quickstart/*

I checked the role mu-pipeline-mu-ci-us-west-2 and it has these permissions:

[
        {
            "Action": [
                "cloudformation:CreateStack",
                "cloudformation:UpdateStack",
                "cloudformation:DescribeStackEvents"
            ],
            "Resource": [
                "arn:aws:cloudformation:us-west-2:324320755747:stack/mu-repo-mu/*",
                "arn:aws:cloudformation:us-west-2:324320755747:stack/mu-app-mu/*",
                "arn:aws:cloudformation:us-west-2:324320755747:stack/mu-bucket-codedeploy/*"
            ],
            "Effect": "Allow"
        },

It seems that the resource it granted access to does not match the stack it attempted to access. As I type this I wonder if it's related to the - in the repository name mu-quickstart?

mu 1.5.1
osx
my.yml

environments:
  - name: acceptance
  - name: production
service:
  port: 80
  healthEndpoint: /
  pathPatterns:
    - /*
  pipeline:
    source:
      provider: GitHub
      repo: mneil/mu-quickstart

[mneil]

Quick update:

I've dug through context, pipeline, and into pipeline_common.serviceFinder. That seems like the most likely place for this to possibly happen. I tested loading my own git repo/mu.yml file manually with Context.InitializeConfigFromFile and have been unable to reproduce. Ultimately the serviceFinder tests implement a generated config similar to what my quickstart app produced.

This issue definitely occured, there are logs in cloudwatch for it here https://us-west-2.console.aws.amazon.com/cloudwatch/home?region=us-west-2#logEventViewer:group=/aws/codebuild/mu-pipeline-mu-image;stream=9264ba60-3463-48f6-9891-bad3e7cfab95;start=2018-08-20T21:36:40Z, but I am unable to reproduce it.

Rerunning mu pipeline up a second time resolved it. My initial guess was that redeploys and initial stack creation ran through difference code paths. I'm sure at some point they diverge but not in any of the configuration loading/parsing or ServiceName generation where this issue is most likely.

I'm leaving up but feel free to close after looking.

Thanks!

[cplee]

Looks like the ServiceName wasn't properly defined for the CFN stack that manages the pipeline IAM roles. The service name comes from a couple possible places for mu pipeline up command:

• the mu.yml file (service.name)
• the name of the directory the mu.yml file is in

Since i don't see a service name in mu.yml, i'm assuming it came from the second option. Are you pointing to a specific mu.yml file via mu -c path/to/mu.yml pipeline up? If so, can you share the exact command that was run? If not, what was the current working directory that you were in when running the mu pipeline up command? Was there a mu.yml file in that directory?

(see: https://github.com/stelligent/mu/blob/develop/common/context.go#L45-L48)

[mneil]

I think the directory name might have been it. I did not specify a specific yaml file. The command I ran was:

mu pipeline up

I had initially created the folder then followed the quickstart guide. Thinking back I must have named the folder mu then later (after it failed) renamed it to match my repo name. I renamed it entirely by chance because I wanted to clone this repo (also named mu) and didn't want to confuse mu core with my quickstart mu.

I found another issue earlier today that I'm almost positive relates to this. Issue #300