Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Announcement: Config as code enhancements, including support for labels and custom fields

Hey everyone, Josh here from the Compass product team and I’m really excited to share that config as code now supports managing component labels, custom fields, the lifecycle attribute, and changing component type!

Config as code is a way to describe and manage your components using a "compass.yaml file" that gets added to your git repository. When a component is managed by config as code, it’s catalog information can only be updated by committing changes to the yaml file, which allows for governance over who can make changes and version control of component metadata.

The example yaml file below demonstrates how to use the new features if you’re already familiar with config as code. Checkout our docs for complete details on how to get started with config as code including more information on how to use these new fields.

configVersion: 1
name: example-service
id: 'ari:cloud:compass:d7141038-29ed-438b-901a-cebe65515bab:component/0fa12d64-d15f-4b2e-96fb-5b84203bf3c9/2b5abb73-0a29-465a-8bfd-afc69e5af0e8'
description: This is an example service.
typeId: SERVICE
ownerId: null
fields:
  tier: 4
  lifecycle: Active
links:
  - name: Source Code
    type: REPOSITORY
    url: 'https://bitbucket.org/example/service'
labels:
  - 'foo:bar'
  - baz
customFields:
  - name: platform
    type: text
    value: web
  - name: reviewed
    type: boolean
    value: true
relationships:
  DEPENDS_ON:
    - 'ari:cloud:compass:00000000-0000-0000-0000-000000000000:component/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-00000000000'
    - 'ari:cloud:compass:00000000-0000-0000-0000-000000000000:component/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-00000000000'

# Learn more about formatting compass.yml:
# https://go.atlassian.com/compass-yml-format

You may also notice that we now have a "configVersion" key as well; this is currently optional and the only supported "configVersion" today is "1".

What’s next for config as code you may ask? Next up we’ll be working on allowing you to create new components by simply adding a compass.yaml file to your repository which means we’ll remove the requirement to first create the component in the UI to obtain the ARI.

If you aren’t already managing your components through config as code learn more about it today! Let us know what you think and what else you’d like to see config as code do.

4 comments

Richard Simpson March 21, 2023

> Next up we’ll be working on allowing you to create new components by simply adding a compass.yaml file to your repository which means we’ll remove the requirement to first create the component in the UI to obtain the ARI.

Heck yah! We honestly decided against config-as-code because of this 
requirement. Dropping the requirement for ARNs (including owner refs and component refs!!) would def make use reconsider that.

Also would add that it'd be great to have a yaml JSON Schema so that developers editing the config in an editor like VS Code can get a rich auto complete and validation experience. ++ If it's an extension.

Like # people like this
Josh Campbell
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 22, 2023

AWESOME idea thanks Richard!

Hear you on the ID requirement for sure, I'm really excited to ship the create from yaml work myself! Hope you get back around to config as code after we ship it :)

Like Richard Simpson likes this
Thom Smith
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 27, 2023

Hey, I've been evaluating implementing Compass within my organisation and the biggest thing that is putting me off is the opaque ARI IDs that are used for teams and other components.

The UX for a developer maintaining the compass.yml, seems very poor in this regard, forcing developers to go look up these IDs. Removing the requirement of the "id" field and the component to be first created in the UI is a good start but the "depends_on" and ownerId" fields should also be human-readable fields.

Like Josh Campbell likes this
Josh Campbell
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 27, 2023

Hey Thom! The ability to create a new component without first getting an ARI is imminently coming - the team is hard at work wrapping this up as we speak!

I hear you on the ARI pain. We are very aware of this. The ID is useful because if the name of the owner team or a dependency changes you don't need to update your yaml file. And component names are not unique in Compass as well so again ID is helpful here. But obviously the ARIs are unwieldy and not human friendly, and it also requires you to hit the UI or API (another step) to find these things.

What if you could annotate the owner and dependency fields with a string? So you would still need to add the ARI but you could also add an "alias" key, then while reading the yaml you have a human friendly reference. Helpful for readability?

I assume the preference would be to just be able to use strings and declare the team of the team or component? Somewhat related... do you have components in your catalog that share the same name? Looking to understand how many customers appreciate the fact that the Compass catalog does not enforce uniqueness of component names.

Thom very much appreciate you raising this, it really helps with prioritizing when we hear how painful something is and your feedback is super valuable. Cheers!

Like # people like this

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events