#spacelift (2024-04)

@James Humphries @marcinw

What about if a tag is made to point at a different commit? I don’t believe the spacelift registry uses git tags. At least it used to only use version files.

https://docs.spacelift.io/vendors/terraform/module-registry#git-repository-structure

when i trigger the module in the spacelift registry, it creates a version from the tags available

there’s also this part of the doc on the tag-driven module workflow: https://docs.spacelift.io/concepts/policy/push-policy/#tag-driven-terraform-module-release-flow

I’ve found you actually do not need the spacelift config file at all. I was able to use the “raw git” option to import a public terraform module from github to my spacelift private registry. Click “trigger” and watch it create a version. The module I used only has one version, so not sure if it would create a version for every tag…

Hey, sorry for the slow reply on this one. I didn’t spot it in this slack server.

In the future, feel free to reach out to spacelift support directly via a shared slack channel and/or the chat bubble on our page. We may get to things a bit quicker

When spacelift registers a new version for a module, we store the head commit for the ref. (Or you can make a version directly from a commit sha). This means that if the tag is moved, I don’t think spacelift will update it.

When an end user of the module requests a download for the module, the spacelift registry will point them to the git repo at that specific commit. This means that if the repository of code is removed, the module download will not work.

As for the removal of git tags and that corrolating to the version being removed in spacelift, I don’t think we handle this automatically right now through push policies or automatically, but please feel free to submit a feature request for this.

In the meantime you can manually mark a version as “bad” as per the docs here: https://docs.spacelift.io/vendors/terraform/module-registry#marking-versions-as-bad

I’ll raise something internally to improve the documentation in this area Thanks for raising this, and feel free to reach out if you have any other questions.

Note: I see you did ask in the spacelift server Thanks!

Yes I did ask in our shared channel also. But I thought someone in the community here might know the answer also, or just be interested. So I think in my terms, ref immutability is there, a moved tag wouldn’t change the version in the spacelift registry.

Correct

But availability is not handled by the spacelift registry, so for that concern I’d have to find another approach. Maybe clone/mirror the module so it’s under my control, and register it with spacelift from there?

From an availability perspective, this is something cloudsmith solves. They can act as a pull through cache for anything, including terraform modules and providers.

@Erik Osterman (Cloud Posse) what is cloudsmith? i don’t see any links in that channel…

https://help.cloudsmith.io/docs/terraform-modules-repository It’s an alternative module repository in this case. But overall it’s an artifact storage system

oh wait, there’s an embedded link in one of the messages…

well i don’t want to pay for another registry lol. feature request for spacelift coming in soon!

I’d love a feature request for spacelift If spacelift is lacking in some way and we can improve so people dont have to get other products, then that’s great.

i actually had a similar question for external/public terraform providers, and the spacelift registry, so a pull-through cache would be handy

As a non spacelift employee, I’ve seen a lot of movement lately from the seal-io guys, and they recently made this: https://github.com/seal-io/hermitcrab which works really well for providers. but because modules are pulled from source in terraform/opentofu its a bit more difficult to do

Ok, feature request submitted… https://portal.feedback.us.pendo.io/app/#/case/383664

Thanks!