Issue after updating tag

[freimair]

Hi there,

I created a release github, but, unfortunately, on the wrong commit. I only became aware of the issue after building it once on jitpack. Now, I updated the tag to point to the correct commit and now the git release is sound.

However, jitpack does not update the tag. Is this an issue? or is this by design?

this is what 0.4.7.2 should be:
https://jitpack.io/com/github/JesusMcCloud/netlayer/0472-0e57f3f622-1/build.log

this is what 0.4.7.2 is:
https://jitpack.io/com/github/JesusMcCloud/netlayer/0.4.7.2/build.log

Thanks!

[jitpack-io]

Hi,

You can delete a release within 7 days and then rebuild. It should pick up the new tag.

[freimair]

Hi,
thanks for the tip. However, I tried that multiple times. Only then did I open this issue.

However, now, a few days later, jitpack says that there is no 0.4.7.2. That is expected, since I deleted the very release and with it the tag again to work around the issue.

I just created the tag again on the correct position and now, jitpack builds everything as it should.

So it seems to me that I have run in some caching timeout. I mean, that I have been too fast with deleting an rebuilding the tag that the wrong commit hash was still in a short-lived cache?

Anyhow, thanks for your time!

[freimair]

Hi there, I did run into the very same issue today.

Please take a look at these logs and their first few lines.

should be: https://jitpack.io/com/github/JesusMcCloud/netlayer/3b2fdc8f07/build.log
is: https://jitpack.io/com/github/JesusMcCloud/netlayer/0.6.1/build.log

again, I moved the tag.

Deleting the release and rebuilding it does not work. It seems to me that jitpack is not fetching updated tags correctly. What can I do?

[freimair]

I looked some more into the behaviour and found that once a tag is set, jitpack does not forget about it for a certain amount of time.

git structure: ...-1-2-3-master

Steps to reproduce:

1. Create a tag "foo" at commit 2. Build tag "foo" with jitpack. Works.
2. Delete build of tag "foo" at jitpack.
3. Delete tag from the repo and try to build the tag. Jitpack says Tag or commit 'foo' not found. Rechecking. So at least jitpack does delete the tag. Works.
4. Add tag "foo" to commit 3. Build tag "foo" with jitpack. Jitpack builds commit 2!

last time, after 3 days time, the correct tag has been built.

[freimair]

Adding a dummy commit on top does not change the behaviour as well. (following the suggestion in bisq-network/bisq#2010 (comment))

building "jitpackfix-SNAPSHOT" does result in building the correct commit.
Only the tag seems to be stuck.

[freimair]

could it be a reincarnated #1025?

It is now several days after and the behaviour is still the same. The tag is stuck, no matter what I do.

[freimair]

I just investigated some more and this is what I found:

• the git repository fetched by jitpack is up to date (checked like so) - the tag is on the correct commit
• I just rebuild the netlayer package and it succeeded. However, again with the wrong commit id.
• I again looked at the build.log and noticed that the very first line says:
  Start: Wed Nov 28 11:57:13 UTC 2018 [...]
• in contrast, my git check build log starts with
  Start: Sun Dec 2 22:01:48 UTC 2018 [...]

And I started the 0.6.1 build right after my git check build. So, in fact, the tag 0.6.1 build.log and most probably the build itself served by jitpack is a few days old although I just ran it and got a green light.

[jitpack-io]

Hi,

Thanks for the detailed steps!
JitPack caches tags for about 1 hour but should have cleared this cache when you delete a build. We're working on a fix for it

[jdimeo]

This is happening to me as well, even after multiple hours of waiting. Anything we can do to trigger a clear or flush or something via the API?

[freimair]

I still encounter the issue. Again my analysis:

• jitpack does build the correct commit
• the CDN does deliver the first version of a file only, for eternity?
  for example:
  • this is the build report. It says that no artifacts have been found.
  • I deleted the build and triggered one again (still resulting in the old build.log). However, this time, the build has been kind of successful as e.g. this build artifact exists

[1993hzw]

This is happening to me as well

[jitpack-io]

Hi,

In some cases the build.log is cached by the browser so it it's forth doing a hard refresh.
If it is cached by CDN then you could append a query string to the build log url. Something like /build.log?random

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.