controller_credential_types.yml

In these files we configure the credential types for automation controller.
we will probably do this on the global configuration (ALL).

The infra.aap_configuration collection expects the vaules in the variable: controller_credential_types. As we intend to configure everything just once, we spit the set of vars into the environments and join the lists in the main.yml, before calling the collection. If there are no credential_types defined, do not add this file. If you do, ensure the file is present in all branches, with the correct content, described below.

variables

The api understands the following structure:

{
    "name": "",
    "description": "",
    "kind": null,
    "inputs": {},
    "injectors": {}
}

Below you can see examples of how this is used.

group_vars/all/controller_credential_types.yml

Here we see an example of the configuration for a credential type to pull items from automation hub.

---
controller_credential_types_all:

  - name: automation_hub
    description: automation hub
    kind: cloud
    inputs:
      fields:
        - id: verify_ssl
          type: boolean
          label: Verify SSL
        - id: hostname
          type: string
          label: Hostname
        - id: username
          type: string
          label: Username
        - id: password
          type: string
          label: Password
          secret: true
        - id: token
          type: string
          label: Token
          secret: true
      required:
        - hostname
    injectors:
      env:
        AH_PASSWORD: !unsafe "{{ password }}"
        AH_USERNAME: !unsafe "{{ username }}"
        AH_HOST: !unsafe "{{ hostname }}"
        AH_API_TOKEN: !unsafe "{{ token }}"
        AH_VERIFY_SSL: !unsafe "{{ verify_ssl }}"
      extra_vars:
        ah_password: !unsafe "{{ password }}"
        ah_username: !unsafe "{{ username }}"
        ah_host: !unsafe "{{ hostname }}"
        ah_token: !unsafe "{{ token }}"
        ah_validate_certs: !unsafe "{{ verify_ssl }}"
...

But you can already see that the variable name used here has the "_all" extension, so the variable will not be overridden as this is not quite a inventory.
Why we do this, will become clear in a moment.

group_vars/dev/controller_credential_types.yml

As we do not configure extra credential_types in development, this file is an empty set.

---
controller_credential_types_dev: []
  # No extra config exists
...

Here the variable has the "_dev" extension, so the variable will not be overridden.

group_vars/prod/controller_credential_types.yml

As we do not configure extra credential_types in prod, this file is an empty set.

---
controller_credential_types_prod: []
  # No extra config exists
...

Here the variable has the "_prod" extension, so the variable will not be overridden.

When we run a pipeline for a certain environment, the inventory structure will provide us with 2 variables: - controller_credential_types_all
- controller_credential_types_

We will merge these 2 variables into 1: controller_credential_types and feed this to the infra.aap_configuration.controller_credential_types role.
In main.yml the merge of the variables is done by this piece of code:

    - name: Set the controller vars
      ansible.builtin.set_fact:
        controller_credential_types: >
          {{ controller_credential_types_all |
          community.general.lists_mergeby(vars['controller_credential_types_' + branch_name],
          'name', recursive=true, list_merge='append') }}

This results in the controller_credential_types variable the collection needs.

Back