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

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?

[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 😉

[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.