Verificando autenticación…

Skip to main content

Direct usage of the code/version component

This page is for those who want to include the code/version component directly in their pipeline, outside of the standard language pipelines.

If you use golang-service, java-service, react-service or python-service, go to the user guide — the component is already configured there.

When it makes sense to use it directly​

  • Your project uses a stack not covered by the standard pipelines.
  • You have a monorepo with multiple independently versioned components.
  • You need explicit control over the stage, runners, or job inputs.

How to include it​

include:
  - component: $CI_SERVER_FQDN/latamairlines/andes/pipelines/components/code/version@1.0.0
    inputs:
      job_name: "detect-version"
      stage: "prepare"

stages:
  - prepare
  - build

build-image:
  stage: build
  needs:
    - job: detect-version
      artifacts: true
  script:
    - echo "Publishing version ${VERSION}"
    - docker build -t my-image:${VERSION_SEMVER_OCI} .

Always pin the component version (@1.0.0) to avoid unexpected changes in your pipeline.

Complementary component: deploy/publish​

The code/version component only detects and calculates — it does not create Git tags or publish releases. To complete the cycle you need the deploy/publish component, which consumes the artifacts from version.env and handles:

  • Creating the Git tag in the repository.
  • Publishing the image to the corresponding registry.
  • Registering the release in GitLab with the notes from CHANGELOG.md.
  • Deleting RC tags when a stable is published.

The standard language pipelines include both components preconfigured. If you use code/version directly, you also need to include deploy/publish or implement that logic yourself.

Full reference​

Available inputs, stack detection logic, variables produced in version.env, and special behaviors (idempotence, auto patch bump, rolling OCI tags) are documented in the component README:

README — code/version component

ANDES context​

When using the component directly, the same rules apply as with the standard pipelines:

  • On the main branch with the tbd strategy (the default), the component automatically generates an RC. To publish a stable, pass release_candidate with the Jira ticket for the change.
  • validation_mode resolves to strict on main and MRs targeting main. Make sure your CHANGELOG.md has an entry with content for the VERSION_CORE before merging.
  • The release to production process is the same as with the standard pipelines. See Release to production.

References​