How to use extend with Gitlab CI-Component?

Question

I have this GitLab CI-Component:

spec:
  inputs:
    message:
      default: test
---
.test-component:
  script:
    - echo "$[[ inputs.message ]]"

Also I have this Pipeline:

stages:
  - test

include:
  - component: [my-gitlab-url]/[project-path]/test-component@[commit-sha]
    inputs:
      message: "This is a test job!"

Demo job:
  stage: test
  extends:
    - test-component
  before_script:
    - echo "This is before script!"
  after_script:
    - echo "This is after script!"

The "Demo job" is executed like I wanted (so it works perfectly as a template substitution there). But it also executes the component on its own. But I want to work with components like templates so I can not only outsource jobs but also sub parts of jobs. How can I stop it from executing on its own?

This shows the two jobs (but I only want "Demo job" to be executed):

Chromatid

Did you find a solution? Thank you – Aftermath

Answer 1

In your Demo Job you're trying to extend the template test-component but that doesn't exist. You defined the template .test-component, but are trying to include it without the .. Add the . in your job and run it again:

Demo job:
  stage: test
  extends:
    - .test-component
  before_script:
    - echo "This is before script!"
  after_script:
    - echo "This is after script!"

Interphone

Answer 2

You can configure the catalog job with when: never, and then include the template in a job within the projects CI/CD config. Then, you can set rules accordingly.

It's late, so not providing an extremely stripped down version... real world examples are sometimes better anyway.

# netbird_install.yml

spec:
  inputs:
    stage:
      default: test
    netbird_registration_token:
      description: \[DO NOT SET\] Registration token should be configured as CI/CD variable. Must be masked.
      default: $NETBIRD_REGISTRATION_TOKEN
---

.netbird_install:
  stage: $[[ inputs.stage ]]
  when: never
  script: 
    - |
      apt-get update
      apt-get install ca-certificates curl gnupg -y
      curl -sSL https://pkgs.netbird.io/debian/public.key | gpg --dearmor --output /usr/share/keyrings/netbird-archive-keyring.gpg
      echo 'deb [signed-by=/usr/share/keyrings/netbird-archive-keyring.gpg] https://pkgs.netbird.io/debian stable main' | tee /etc/apt/sources.list.d/netbird.list
      apt update && apt install netbird iputils-ping -y

    - netbird up --setup-key $[[ inputs.netbird_registration_token ]]
    - ping -c 15 100.78.90.183
    

# .gitlab-ci.yml

stages:
  - deploy

include:
  - component: $CI_SERVER_FQDN/<my-group>/cicd-components/[email protected]
    inputs:
      stage: deploy

deploy_job_with_vpn:
  stage: deploy
  script:
    - !reference [.netbird_install, script]
    - echo "Getting netbird status:"
    - netbird status
  after_script:
    - echo "Did the above work?"
  when: always

Job output:

redacted environment prep
$ apt-get update # collapsed multi-line command
$ netbird up --setup-key $NETBIRD_REGISTRATION_TOKEN
Connected
$ ping -c 13 100.78.90.183
PING 100.78.90.183 (100.78.90.183) 56(84) bytes of data.
From 100.78.51.105 icmp_seq=3 Destination Host Unreachable
64 bytes from 100.78.90.183: icmp_seq=1 ttl=64 time=135 ms
64 bytes from 100.78.90.183: icmp_seq=2 ttl=64 time=168 ms
64 bytes from 100.78.90.183: icmp_seq=3 ttl=64 time=84.9 ms
--- 100.78.90.183 ping statistics ---
...
$ echo "Getting netbird status:"
Getting netbird status:
$ netbird status
OS: linux/amd64
Daemon version: 0.28.9
CLI version: 0.28.9
Management: Connected
Signal: Connected
Relays: 2/2 Available
Nameservers: 0/0 Available
FQDN: runner-<redacted>.netbird.cloud
NetBird IP: 100.78.51.105/16
Interface type: Kernel
Quantum resistance: false
Routes: -
Peers count: 1/2 Connected
Running after_script 00:00
Running after script...
$ echo "Did the above work?"
Did the above work?
Cleaning up project directory and file based variables 00:01
Job succeeded

Your initial post helped me, so hoping this returns the favor!

Etude

I used your solution also for some time. But now I just use the point before the component name. It should be sufficient to stop the job from automatically executing. But still thank you for sharing your solution :) – Chromatid

Are you still using the !reference tag to include the script? Curious to see your implementation for including the component in a broader job. Looking to introduce our engineering team to components so seeing how you are doing it would be helpful for documenting best / simplest practices. – Etude

It depends. For simple script parts that are used for multiple Jobs/Components we use !reference. But for larger (CI independent) stuff (for example filtering multiple coverage reports to calculate the overall code coverage) we prefer scripts that are then executed in the pipeline. The advantage is that we can test these and also use them localy. Also other developers who know the script language (for example bash) can maintain them more easily even if they don't have knowledge about YAML and Pipelines. – Chromatid

Beautiful, thanks for the clarification! – Etude