Latest version broke the giving a tag as base about paths-filter

[sconix]

I believe you are correct, using -f to force update the local refs would (or at least could) result comparing to a wrong commit. I did quick test locally that if I force update tag locally, then push it to origin and then try to update tags it will say that would clobber existing tag, even though after force pull tags the commit still points to the exact same commit. So it can be that the commit would be correct, but if the tag would have been previously force updated from another clone then I believe using -f would result in comparing to wrong commit.

So to summarize I tested this without the workaround and it works now and afaik it works exactly as it should. Will let you know if we discover a case where this ain't true, but so far looks really good. So thanks for fixing these issues! This is really useful action for us.

[dorny]

Yes you are right. Thanks for reporting the issue. I will try to fix it asap.

[sconix]

Thanks for the quick fix, however small issue remains. The finding merge base errors out with: Error: The process '/usr/bin/git' failed with exit code 1

Searching for merge-base dev-deploy...dev-release
  /usr/bin/git show-ref dev-deploy
  /usr/bin/git fetch --no-tags --depth=100 origin dev-deploy dev-release
  From https://github.com/***
   * tag               dev-deploy -> FETCH_HEAD
   * tag               dev-release -> FETCH_HEAD
  /usr/bin/git show-ref dev-deploy
  /usr/bin/git fetch --tags --depth=1 origin dev-deploy dev-release
  From https://github.com/***
   * tag               dev-deploy    -> FETCH_HEAD
   * tag               dev-release   -> FETCH_HEAD
   * [new tag]         dev-deploy    -> dev-deploy
   ! [rejected]        dev-release   -> dev-release  (would clobber existing tag)
   * [new tag]         stage-release -> stage-release
   * [new tag]         test-release  -> test-release
   * [new tag]         v1.0.0        -> v1.0.0
   * [new tag]         v2.0.0        -> v2.0.0
   * [new tag]         v2.0.0-1      -> v2.0.0-1
Error: The process '/usr/bin/git' failed with exit code 1

As a workaround we added running of the 'git fetch --tags --depth=1 origin dev-deploy dev-release' in previous step and ignored the none zero exit code, this way the paths-filter step won't error out and works as it should with tag as a base. With this workaround the output of searching for merge-base step is:

Searching for merge-base dev-deploy...dev-release
  /usr/bin/git show-ref dev-deploy
  9df32659538ce5ddf1d475c42b17156db3a08c98 refs/tags/dev-deploy
  /usr/bin/git merge-base refs/tags/dev-deploy dev-release
  /usr/bin/git fetch --no-tags --depth=100 origin dev-deploy dev-release
  From https://github.com/***
   * tag               dev-deploy -> FETCH_HEAD
   * tag               dev-release -> FETCH_HEAD
  /usr/bin/git rev-list --count --all
  212
  /usr/bin/git merge-base refs/tags/dev-deploy dev-release
  9df32659538ce5ddf1d475c42b17156db3a08c98

[dorny]

I see that not only your base is a tag but also a current ref is a tag. That's scenario I must admit I didn't test. I will add it to the list.

Anyway from the logs it seems it would normally work.
However in your case you already had dev-release tag locally, just pointing to different commit.
That's where the (would clobber existing tag) error probably comes from.
Adding -f argument to git fetch should do the trick.
I will look into it during this weekend.

[sconix]

Yes in this particular case thats correct that both are tags did not realize to mention that (nor test the normal case) in the issue since the original flaw was clearly related to the tag as a base. Anyway it seems to work correctly with the workaround, so most likely your assumption would be the correct fix. Thank you for looking into this!

[dorny]

Would be possible that your dev-release tag was updated somewhere between your workflow being triggered and paths-filter being executed? I tested few scenarios and this seems to be the only way how to get error: ! [rejected] dev-release -> dev-release (would clobber existing tag).

Originally I thought I will add -f switch to force update local refs but that would cause change detection against different commit than one your workflow was triggered with.

I think this error can be safely ignored.
I just updated the v2 branch - it will ignore the error and continue as usual.

Could you please remove your workaround and test if it works for you now ?