Please help fill in this template with all the details to help others help you more efficiently. Use formatting blocks for code, config, logs and ensure to remove sensitive data.
Problem to solve
In your CI/CD components documentation you have the following example of a complex CI/CD component.
├── templates/
│ ├── my-simple-component.yml
│ └── my-complex-component/
│ ├── template.yml
│ ├── Dockerfile
│ └── test.sh
├── LICENSE.md
├── README.md
└── .gitlab-ci.yml
I would like to use this pattern, but I ran into the following problem. Consider the following fragment.
“$[[ inputs.job-export-name ]]”:
image: $[[ inputs.builder-image-name ]]:$[[ inputs.builder-image-tag ]]
stage: $[[ inputs.stage ]]
script:
- *some-script
The problem is there is a circular dependency. It makes sense that the default input for builder-image-tag would match whatever container version was built for the component. If you simply update the version manually in the component and the container tagging logic then you’re done.
The complication arises when you want to use a tool like semantic-release that calculates the version automatically. While you could run this on your local Git repo to calculate the version it seems like it would be better to have this done automatically in the CI/CD pipeline. In this case you would submit a new PR with the changes, the build would run and calculate the version, but the actual default value for the Component’s image will not change unless you commit the calculated container version back to the repo. You could use ‘latest’ but then the containers will not be version-locked to a specific container that was built for that Component. You could version the container separately and then update the value manually in the Component, but this seems like a workaround/hack more than a solution.
Could someone please explain more about the intended flow in the documentation example and how the GitLab team expected developers to implement it according to best practices?