Jsdelivr: jsDelivr's GitHub CDN files don't match GitHub's Actual Release files

[iskitz]

problem

ionify's jsDelivr 0.1 GitHub release of web.js doesn't match GitHub's actual 0.1 release of web.js.

background

I created ionify's 0.1 GitHub Release to ensure ionify's presence as a jsDelivr GitHub Package for use like:

// load any ionify GitHub release, commit, or branch via jsDelivr
https://cdn.jsdelivr.net/gh/ionify/ionify@version/file

investigation

I suspect that when jsDelivr synced ionify from GitHub, it used all files found in the 0.1 branch that coexisted with the 0.1 release & tag on GitHub. I don't know how or if jsDelivr can distinguish between GitHub branches & tags but I've tried these unsuccessful steps to correct the issue:

• deleted the old 0.1 GitHub branch
• verified that the 0.1 GitHub tag does point to the expected web.js & other files
• deleted the 0.1 GitHub Release
• recreated the 0.1 GitHub Release
• verified that jsDelivr still serves the old incorrect 0.1 branch's files

I've found looking back through my past GitHub commits that the 0.1 branch used the same https://github.com/ionify/ionify/tree/0.1 location as the new 0.1 tag which may be what jsDelivr used as well...

How can I or we fix this?

I don't see or know of a way to cause jsDelivr to refetch or sync ionify's actual 0.1 GitHub Release but I'd like it to.

Is the pending Purge cache tool meant to help with problems like this?

If so, can you say when it'll be available & in the meanwhile, can we solve this problem without it?

[MartinKolarik]

In general, releases are checked before branches. But if a branch exists first and is accessed, then a release gets created with the same name, things are likely to get mixed up since they share the same namespace.

All files are treated as immutable so there's not really an easy way to fix this other than making a new release.

The purge tool only applies to CDN-level cache for this case:

// use a version range instead of a specific version
https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js
https://cdn.jsdelivr.net/npm/jquery@3/dist/jquery.min.js

If you use a fully qualified version (i.e., exactly the release version, not just part of it), that's not expected to ever change.

[iskitz]

I agree with & expect this

If you use a fully qualified version (i.e., exactly the release version, not just part of it), that's not expected to ever change.

but it’s unfortunate that any branch & tag mixups are irreversible. As it is, jsDelivr & GitHub content are different for the same 0.1 ionify release.

GitHub didn’t give any warning that it was duplicating an existing branch name when creating the 0.1 release & automatic tag.

Compounding the issue further, GitHub also doesn't provide a way to delete the 0.1 tag as far as I could see.

[MartinKolarik]

Releases and tags can be deleted from GitHub via the releases tab.

[iskitz]

🤔Hmmm . . . really doesn't seem so.

I can & have only been able to delete a Release not a repo Tag via GitHub. After deleting the Release the tag remains and there's no UI I could find to delete it. I'll try doing that directly via git.

Will jsDelivr continue to show ionify's 0.1 release even after deleting the release & tag from GitHub? I'm assuming yes per this note:

We use a permanent S3 storage to ensure all files remain available even if GitHub goes down, or a repository or a release is deleted by its author. Files are fetched directly from GitHub only the first time, or when S3 goes down.

The last sentence re: fetching "from GitHub . . . when S3 goes down" did catch my eye as a possible way to fix this...

[MartinKolarik]

I can & have only been able to delete a Release not a repo Tag via GitHub. After deleting the Release the tag remains and there's no UI I could find to delete it. I'll try doing that directly via git.

Will jsDelivr continue to show ionify's 0.1 release even after deleting the release & tag from GitHub? I'm assuming yes per this note:

The files will remain available but won't be listed on the website as the version list is periodically refreshed from GitHub.

[iskitz]

The files will remain available but won't be listed on the website as the version list is periodically refreshed from GitHub.

What happens if I recreate the 0.1 tag on GitHub? Will the files be listed on jsDelivr’s site?

re: tag deletion via GitHub UI:

I can only delete the Release. I can’t delete the tag:

[MartinKolarik]

What happens if I recreate the 0.1 tag on GitHub? Will the files be listed on jsDelivr’s site?

yes but likely the wrong ones again

First delete the release, then you should be able to delete the tag.

[iskitz]

First delete the release, then you should be able to delete the tag.

Ok. I see what I missed. I was able to delete both the release & tag. Thanks for being patient 😄

I just created a new ionify 0.1.0 release & am waiting to see if jsDelivr stops showing the 0.1 release and instead shows this new accurate 0.1.0 one...

[iskitz]

Ok. I'm happy with the workaround of:

1. deleting the unwanted release & its tag on GitHub
2. creating a new differently named release on GitHub
3. having jsDelivr auto-hide the old unwanted release
4. having jsDelivr auto-show the new release

@MartinKolarik I do think it'll help to add a note to the Tips for package authors section of the Features page re: potential branch & release tag confusion:

Tips for package authors

• make sure the provided files work in browser (use UMD)
• use semver for versioning (this is enforced by npm but not by GitHub)
• if you distribute minified JS/CSS files, also include source maps for those files
• if you don't want to provide minified files, it's fine - we'll handle that for you
• avoid release names that duplicate branch names if the branch & release have different content since they can't be changed once published to jsDelivr

I bolded my suggested addition ☝️ to make it obvious to you, not to imply its more important than the others, or that it should be bolded if added & published to the site. I would love to see something like this added though. It would've saved me, and you, the headache & time spent discussing & working around this.

Thanks for your help, patience & conversation. Glad to understand what happened and how to workaround it. I don't plan to run into this again, but now I've got a workaround if I do 😉