config-as-code practicalities

[Keith Furnell]

We have the following questions with respect to some apparent barriers to the use of config-as-code with Compass:

1. GUIDs in compass.yml
   The use of GUIDs for (single_select, multi_select_user & user) customFields values, relationships, and presumably custom typeIds, makes modification/review of these painful outside of the UI. Accepting that these items could be renamed, is it currently possible, or is it planned to become possible, to allow use of the mapped name strings as an alternative for GUIDs in the YAML?
2. Unsupported fields
   At least the Details and Documents fields are apparently not currently supported by config-as-code. Would it be possible to at least highlight in the UI such fields that cannot (currently) be represented in compass.yml?
3. Config-as-code config 
   Alongside the Automatic Import switch under Apps > Configure Git Hub, there is also Config as code switch which is disabled by default. Is this documented somewhere?
4. Roadmap visibility
   Is there any public visibility for upcoming features/fixes that might allow earlier adoption, with the knowledge that wrinkles are at least due to be ironed out?

[Enrique Serrano Valle · Accepted solution]

@Keith Furnell thank you for reaching out! Let me try to address each one of the questions that you raise above.

1. Config-as-code custom field types and values

There's an initiative in an Early Access Program for some Compass customers to do precisely as you suggest and start using the human-readable values in config-as-code for a few of the entities that in the general version are still managed by unique identifiers. I expect this rolling out as a mainstream feature in the following months, but if you were interested in piloting this feature as part of your Compass plan, it might be possible to do so. Let me know and I'll put you in contact with one of our program managers to see what we can do in this front.

2. Config-as-code managed fields

You're right that the rich-text details and the documents aren't currently synced with the config-as-code files. For config-as-code managed fields, Compass will lock direct edits in the UI, and in most cases, navigate to the compass.yml file for edits of its value - but I'll make a note of your point as a UX improvement that this isn't as obvious for the fields that aren't directly managed via config-as-code and that remain editable as usual.

3. Config-as-code + automatic import

In a nutshell, enabling automatic import will detect new repository creations from your connected software configuration management tool and import them as new Compass components, so your catalog remains in sync. If you choose to enable config-as-code during automatic import, a pull request will be raised with the related config-as-code file for the newly-discovered component (Compass doesn't directly merge code without user approval).

There's additional documentation in this link.

4. Config-as-code roadmap

You already hit the nail on the head with human-readable values instead of GUIs for config-as-code as the next big item on the list, Keith. I will also reach out to our product owners so they can provide some more specific details on what's coming.

In any case, this is great feedback, so don't hesitate to keep us in the loop with any other suggestions or ideas that you may have. And if you have any other questions, please don't hesitate to reach out. We're here to help!

[Enrique Serrano Valle]

@Keith Furnell just got confirmation that point 1 - human-readable value support in config-as-code - is already generally available in Production (starting last week) supporting custom types, relationships, and single-select and multi-select custom fields.

The config-as-code documentation should have been updated to reflect support for these fields in this link.

[Keith Furnell]

@Enrique Serrano Valle great, I will give this a try. Can I suggest also extending "It can be used instead of the component ID or ARI in some APIs" under documentation of the "slug" attribute in that link?

[Keith Furnell]

@Enrique Serrano Valle whilst using a slug for the relationships is working for me, I am getting the following sync error with custom fields:

with the following compass.yml content:

customFields:
  - name: Jurisdictions
    type: multi_select
    value:
    - 'NSW'
  - name: Language
    type: single_select
    value: 'Java'

and the Language custom field is configured as:

I've tried values with and without quotes - am I missing something?