Param for Tag Name?

[madclouds]

Hello,

I'm really excited to use this plugin. I'm having trouble getting it to work on my project. I have tags such as v5.7.0, but for some reason I wasn't able to find it with analyze_commits(match: 'v*'). Looking at the source I see that the tag format is assumed to be v2.3.4-5-g7685948. I updated my tag to v5.7.0-5-g12345 and it started working.

Maybe I'm using an incorrect tag naming convention? I think it would be best to allow people to name their tags anything, as long as it matches the tag_version_match parameter

          # Tag's format is v2.3.4-5-g7685948
          # See git describe man page for more info
          tag_name = tag.split('-')[0...-2].join('-').strip

I think this line should be changed?

https://github.com/xotahal/fastlane-plugin-semantic_release/blob/79ca32cb219e0daf48cc940030fd167f2fb26923/lib/fastlane/plugin/semantic_release/actions/analyze_commits.rb#L63

[tomgreco]

@xotahal please update this

[joaocac]

Thank you for the plugin, it's fantastic!!

I am also having this issue currently.

Something must have changed (It was working before), but let me provide context.

I work with Gitlab and for some reason when tagging versions with the format v<MAJOR>.<MINOR>.<REV>-<BUILD>-<PLATFORM>-<DIST> (eg. v1.0.0-1-ios-beta) and querying for it, I would get something like v1.0.0-1-ios-beta-x-xxxxxxxx.

So at some point, this made sense and worked. Currently, when queried, Gitlab will send me the tag that I have set v1.0.0-1-ios-beta.

Meaning that currently, this package does not work correctly since it assumes and strips the last two parts after the char -. Then it will try to find the hash for a tag v1.0.0-1 that does not exist, so I get the result and error:

git describe --tags --match=v*-ios-beta
v1.0.0-1-ios-beta
git rev-list -n 1 refs/tags/v1.0.0-1
fatal: ambiguous argument 'refs/tags/v1.0.0-1': unknown revision or path not in the working tree.

Maybe git output changed, maybe just Gitlab but something has changed.

In my case I will replace the tag char - with _ and all should be fine. But this also means that we should try to avoid using - just to be on the safe side.

[xotahal]

Gitlab should have no impact on this I think. Maybe you can check this https://github.com/xotahal/fastlane-plugin-semantic_release/pull/38

[joaocac]

@xotahal Thanks for the link.

In my case my team have a repo that has over 4 months of commits by 3 developers.

I have tried this plugin without any tag in the repo/branch, in this case, it works without any issues. When running the same deployment where a tag exists (with the previously mentioned format) in the repo, I get logs shared in my last comment.

Since my last comment I just tried to change my deployment implementation and shifted from v<MAJOR>.<MINOR>.<REV>-<BUILD>-<PLATFORM>-<DIST> to v<MAJOR>.<MINOR>.<REV>_<BUILD>_<PLATFORM>_<DIST>

From this v1.0.0-1-ios-beta to v1.0.0_1_ios_beta

This change works as expected since it does not conflict with the plugin in the split by -

tag_name = tag.split('-')[0...-2].join('-').strip

[hedy-tech]

@xotahal Hello again.. so after a few checks and verified that my solution didn't work well enough... Here are my findings.

When I run fastlane, somewhere in it, I run the analyze_commits (now in debug mode) and I end up with the following outcome:

[15:04:44]: -----------------------------
[15:04:44]: --- Step: analyze_commits ---
[15:04:44]: -----------------------------
[15:04:44]: $ git describe --tags --match=v*_ios_alpha
[15:04:45]: ▸ v0.12.9_2_ios_alpha
...
[15:04:45]: Error while parsing version from tag  by using tag_version_match - \d+\.\d+\.\d+. Please check if the tag contains version as you expect and if you are using single brackets for tag_version_match parameter.

I started trying out a block of code just to figure out what was going on, and while checking the block in your code:

tag_name = tag.split('-')[0...-2].join('-').strip

Having tag_test to be a string with the value v0.12.9_2_ios_alpha as analyze_commits logs show I have quickly realised that having [0...-2] directly without checking if the array is have at least 3 items makes the script to fail.

I think the issue is due to my following tests:

[15:04:44]: tag_test 'v0.12.9_2_ios_alpha'
[15:04:44]: tag_test.split('-') => ["v0.12.9_2_ios_alpha"]
[15:04:44]: tag_test.split('-')[0...-2] => []
[15:04:44]: tag_test.split('-')[0...-2].join('-') => ''
[15:04:44]: tag_test.split('-')[0...-2].join('-').strip  => ''

I not a ruby developer but I think a possible solution would be:

    ...
    tag_name = tag
    if tag.split('-').length >= 2 then
        tag_name = tag.split('-')[0...-2].join('-').strip
    end
    ...

[dawidvdh]

@hedy-tech your above solution also solved my problem, perhaps open a PR so this can get merged in?

[hedy-tech]

Still not good enough...

I realized that sometimes (some tags) I get the ...-5-g7685948 notation.

And I still didn't understand why.