Semver pattern without 'v' prefix

[Mallear]

👋 Hey, nice project you have here !

I would like to use your action in our TF modules monorepo.
Today, we have a custom workflow creating releases, tags and uploading sources to an external JFrog registry. Our tags follow the pattern module-X.Y.Z.

After setting up this action, it seems it does not detect existing tags and want to create to create an initial release for all modified modules. I've forced the initial release value to 1.0.0 (removing the v prefix) to check if I could trick it.

Release plan:

List of the previous tag, listed to delete:

I didn't find a way to specify custom tag pattern, is there workaround or could it be a feature to implement ?

Thanks !

[virgofx]

Hi @Mallear Great suggestion. You're right, it won't work without the v prefix currently; however, there's no reason why we can't add that feature. I'll work on an enhancement.

Just for clarification, how would you like to handle when there are multiple directories:

e.g.

.
|-- aws
|   |-- vpc-module
|   |-- dns-module

The proper tag would be:

aws/vpc-module/1.3.0
or
aws-vpc-module-1.3.0
or some other combination?

I guess either way, I need to be able to handle the version tag format -- either with and without v prefix, in addition to the delimiter portion. Depending on how you answer it could be one other config variable (e.g. delimiter).

---

Just curious. Since the existing tags were created out of band in your case, I'm guessing they weren't directory subsetted as this action does, meaning you would need to reference the entire repository and then filter to the module path? If you did subset and path filter -- amazing, great job!

Either way, this presents a little bit of a challenge as you have the old tagging scheme plus variance in how the other tags are consumed via module source versus the new mechanism.

If that's the case, I see a great opportunity to add this as a drop in replacement for your existing setup. Assuming we fix the tagging scheme to continue exactly where you've left off, that would enable the following things:

• Subsequent tags for modules would continue based on previous work
• The Wiki would update on next commit and pull in releases BUT the changelogs wouldn't be detected unless you manually go back into the old releases and add the hidden marker to capture it (one time effort if you want to bring those in)
• However, the old tags couldn't be consumed the way the new tags are referenced unless you actually subsetted the module directories so at that point it mostly doesn't make sense to bring in the old ones.

---

Question 2 - What advantage does your team get when you upload the module to the JFrog artifactory? Moving forward would your team have any issues simply referencing the GitHub tags? Access-wise the only difference is the consumer just needs proper GitHub authentication (HTTPS/SSH) to the repo and that's it. Would be able to save some money and potentially reduce complexity; although, usually shops that use JFrog have application teams pushing data there too.

[Mallear]

Hey @virgofx

For my use case, aws-vpc-module-1.3.0 match what we are using today. Or better if we managed to avoid the aws prefix 😃

---

Actually, we work only with AWS, so we do not subset modules per provider but by "category". We have something like this:

.
|-- actions
|   |-- module-a
|-- configuration
|   |-- module-b
|-- permissions
|   |-- module-c

In our workflow, we work with module names and paths to build a zip file with only the module source code. Resulting Github tags follow the pattern module-X-Y-Z and artefacts are send to JFrog following the pattern actions/module/aws.
If there is a way to configure terraform-module-releaser to do the same, it would save us a lot of time 😁

I would like to not go after a big migration that would require to change all our module calls. So, to make a smooth transition, I thought of creating a 1st tag following your pattern with the actual version of the module and switch to terraform-module-releaser. Would this work ?
As we are not working with Git tags directly, that would not impact our actual configuration. We would still be able to extract the version from the tag value and upload the artifact to JFrog like we do today.

---

We migrated from GH tags to JFrog artifacts because we already had a JFrog subscription for backend libraries hosting, so we were already paying for it.
And as our company do not enforce SSH or HTTPS usage with Git so everyone uses the method he/she prefers. This added an overhead in our process/documentation/day to day support so we forced the use of JFrog to be sure everyone has the same configuration.

[luis-garza]

We want to start using this action in an existing project, but it already have published versions without v character, so would be nice have consistency between versions.

We've tried to set the next version in default-first-tag as 1.0.0 but if crashed miserably... 😅

Finally is this feature accepted?
Thanks!

[virgofx]

Hi Luis-Garza, Generally, making this action a drop-in replacement in existing repositories with generic tags will be difficult. This is due to its significant customization and specific naming/delimiter requirements. However, I believe an optional 'v' prefix could be supported, though thorough testing for various edge cases is needed. I'm working on this and hope to have a PR up shortly with a few other naming options; however, note that may not solve your use case.

I would strongly advise adopting the naming pattern consistent with this module 100% in your repository as it will ensure no issues.