Amplify-cli: RFC: Amplify CLI - Tag support

[ammarkarachi]

Problem

Many organization’s workflows requires services to be tagged. Either it’s a requirement for the development or it is to identify all non-essential services and batch remove them.

amplify delete can’t address this easily because it requires a developer instead of an “admin” to manually navigate to every environment and run amplify delete. Sometimes the amplify project is in an abandoned branch that’s difficult to locate.

Solution

By introducing AWS tags to services, we can easily allow backend administrators to locate amplify-generated services and their projects.

How do I enable tags?

amplify init

By default, Amplify CLI places the following tags in a global amplify/tags.json file.

|Key |Value |
|--- |--- |
|user:Stack |{project-env} |
|user:Application |{project-name} |
|user:AmplifyCLIVersion |{cli-version} |

How do I update my tags?

Customers can override the tags in tags.json file in the amplify/ folder by editing the file itself. The file itself must be in the JSON format with the following contents:

[{
    Key: “MY_TAG_KEY”,
    Value: “MY_TAG_VALUE"
}]

When amplify push runs, it’ll take the configuration from tags.json and attach it to every service in the CFN.

Variables

Customers can use specific variables within their tag values to let Amplify CLI know if some information should be auto-filled.
Amplify CLI will provide 3 default variables:

• {project-env}
  
  
  
  • The project environment
  
  
  • Example: prod, dev etc.
  
  
• {project-name}
  
  
  
  • The name of the amplify project
  
  
  • Example: myamplifyapp
  
  
• {cli-version}
  
  
  
  • Amplify CLI version
  
  
  • Example: 4.21.1
  
  

Example: If the customer's project name is myamplifyproject, environment is dev and their tags.json is the following:

[{
    "Key": "myawesomekey",
    "Value": "myvalue-{project-name}-{project-env}"
}]

then the tags get transformed into

[{
    "Key": "myawesomekey",
    "Value": "myvalue-myamplifyproject-dev"
}]

Error handling

• tags.json file is invalid
  
  
  
  • Provide a message to the customer:
  
  
  • Push failed: Tags couldn’t be applied due to an invalid tags.json file.
  
  

Questions for the community:

➡️ Which tags do you think should be there by default?
➡️ What do you think about this workflow using a "amplify/tags.json" file?

[ammarkarachi]

Issue: #365

[mtliendo]

Thanks for putting together this RFC @ammarkarachi!

I think the 3 defaults are fine and cover the basics of what users would expect.

I agree that this flow is easier than the CLI approached discussed in #365, where something like amplify add tags would be more cumbersome than just editing a tags file.

Regarding the json file itself, I just wanted to bring up some discussion points:

• the key and value should be casing insensitive
• it should guard against duplicate tags
• I'm assuming this _is_ ok to keep in version control by default?
• When does tag validation take place; on every resource push?
• I don't have much experience in this area, but is there a built-in way to scaffold tags when in headless mode?

Overall this is a solid proposal and I'm super happy it's getting some more momentum behind it!

[ammarkarachi]

the key and value should be casing insensitive

I am not entirely sure if this makes sense AWS tags are case sensitive by default

it should guard against duplicate tags

Good point! I agree

I'm assuming this is ok to keep in version control by default?

@mtliendo Can you elaborate?

When does tag validation take place; on every resource push?

Yes, tag validation does take place on Amplify push.

I don't have much experience in this area, but is there a built-in way to scaffold tags when in headless mode?

This is something we are looking into right now.

[mtliendo]

Oh nice, I guess I never realized that they were case sensitive by default 😅

Regarding version control, I was just specifically wondering if the tags.json file would not be added to the .gitignore file by default.

[ammarkarachi]

I would like keep the tags.json in version control. This way the tags would remain be uniform across all local repositories and subsequent pushes

[mtliendo]

Sounds good. I appreciate your thoughts on all of this and your time on these questions. Looking forward to seeing this move along!

[ammarkarachi]

[{
    key: “MY_TAG_KEY”,
    value: “MY_TAG_VALUE"
}]

Edited to

[{
    Key: “MY_TAG_KEY”,
    Value: “MY_TAG_VALUE"
}]

[renebrandel]

Another thing to consider:

How to use tags across environments

amplify env add

Then the current environment's tags.json file gets duplicated into the new environment. Just like with all other resources. No different behavior here.

[GeorgeBellTMH]

Will updating the tags file with like a current date or something cause it to re-push all items? Just curious if there is a quick way to do tags that doesn't require a full push?

[ammarkarachi]

Will updating the tags file with like a current date or something cause it to re-push all items? Just curious if there is a quick way to do tags that doesn't require a full push?

If the tags is the only thing that has changed then yes it would not push all your resources but update the tags in this case

[julioxavierr]

+1

[renebrandel]

Hi all - "Tag support" is now available! https://docs.amplify.aws/cli/usage/tags