Before there was an official way to use CI/CD components on GitLab self-managed we've started to backport the OpenTofu CI/CD component as CI/CD templates in GitLab. They are available here.
This changed and there is now an official way for how to use the GitLab maintained CI/CD components in GitLab self-managed.
See the official documentation here and OpenTofu specific documentation here.
With that, I'm wondering if we should deprecate the OpenTofu CI/CD template (backports) now and stop updating them.
The benefit of this is that we don't need to maintain the machinery to create the backports from the template (ugly Makefile hacks) removing code and cognitive load. It also inherently avoids the feature gap between the component and the template.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
@nagyv-gitlab@timofurrer In this issue, you discuss stopping backporting, i.e. stopping to update them. In the deprecation notice, it is a removal.
As far as I understand, the removal may potentially break pipelines, while the deprecation by itself won't. Can you clarify?
I would think it best if the old template stays in place, but provides a warning in the job log. One of the jobs could potentially be made to fail with allow_failure:true in order to draw attention to it, providing information in the job log that the template is deprecated and to use the component instead.
@mbruemmer ah I mixed up the context of this issue / comment (sorry). Original answer is below.
Some of the same reasons apply though - like shipping potentially vulnerable assets.
I'm open to not remove them though in case that's more important. @nagyv-gitlab WDYT?
Original answer
In this issue, you discuss stopping backporting, i.e. stopping to update them. In the deprecation notice, it is a removal.
As far as I understand, the removal may potentially break pipelines, while the deprecation by itself won't. Can you clarify?
True. From my perspective the reason for removing the Terraform templates (from point 1 above) altogether is that we'd be shipping the template with a very outdated and potentially vulnerable terraform because we cannot update it due to the BuSL license of terraform. IMHO, it's not good for our users nor us to ship potentially vulnerable software under one of our templates, when both, templates and the Terraform templates specifically are deprecated. @nagyv-gitlab I suppose it's up to you if we revert that decision and opt to NOT remove the Terraform templates. WDYT?
I would think it best if the old template stays in place, but provides a warning in the job log. [..]
The warning job is already in place for the Terraform templates (from point 1 above), see e.g. here. It also does the things you've mentioned.
It has such minimal monthly usage that removing it will only move us closer to world peace Given the super low usage numbers, I recommend removing the template in 18.0. We can change the template warning to make this clear.
@nagyv-gitlab Thank you for the insight and usage data. Great you have it instrumented!
At this "edge case" level of usage, the breaking change calculator provides a Lowimpact score, which would support removing the template. I would still like to discuss the case more broadly, but will move it to another thread.
@cheryl.li@swiskow For your awareness on breaking changes. The question here is pretty fundamental:
Deprecating the template will keep pipelines running without a breaking change, but may expose customers to vulnerable assets - outdated OpenTofu images in this case. I think that is a case we may see quite often so it may make sense to discuss some general guidance for this situation.
For context, the usage of this particular template is very low.