Enhancement/new script request: "Github-Releases?" #62
Comments
|
This sounds like a nice idea. I encourage you to submit it both to GitHub and also to https://github.com/isaacs/github/issues/new ... |
|
Yes, nice idea indeed! It may not be too difficult to implement since GitHub names the download file based on the api link:
|
|
Please test out the script - https://github.com/Mottie/GitHub-userscripts/wiki/GitHub-download-zip |
|
I hoped so hard that this issue was about releases download stats :x |
|
Holy cow Rob! Just grabbed it and will test it today/tonight. I'm blown away you got something to test so fast. EDIT: Will continue testing but only needed a minute and a couple clicks/tests and I confirm it's exactly what's been missing all along. What are your thoughts on optional #2 above and in addition to renaming the files with commit info, adding certain number of releases below the main repo zip like you did with rawlinks? Or, is the different type of releases going to be an issue if someone has three releases with a single zip and gz, vs someone who's every release has 12 release types (linux/win/mac/etc.)? |
|
Just had a recall good idea of how to address different release types #s etc. if you ever did want to try #2 above...... Underneath the newly-renovated main repo ZIP download, add (through look-ahead API like rawlinks):
Just an idea. I'm envious I wish I could churn out JS fast enough to help write it. Now, if it were dotnet or even a scripting lang like Powershell I'd me a lot more help! :) |
|
The userscript I created is using the standard API. It isn't renaming the files at all. I don't think we can modify the file name once the browser download kicks in, and I'm not sure if it is even possible to use the API to change the file name. As far as I know, GitHub only serves up ZIP and TGZ compressed files. I've never any other file type being served - am I missing something? Is there a case where you'd switch between downloading the repo as a ZIP vs TGZ? Instead of splitting the button, I could add a userscript option that allows you to set your preference.
I'm not really sure what you mean here. Can you mock up something for me to look at? And what page would it be on? I'm guessing the commits page? |
|
Hey sorry for the poor expanation - here's an example of what I mean:
and if you then query the API:
According to what I've been reading on:
So that most recent release of ConEmu as example has 2 executable installers, and 3 total zip/gz/7z bundles for releases. My vision would be to use the API which does list all those under tag assets, to: Create and append a new table element row beneath the ZIP you just enhanced, and across that row/box, split it X number of times depending on ASSETS for that release tag. So, in this case, a 5-way split and perhaps even a mouseover tooltip is best in the event there are a dozen and the slices get a bit thin for actual text (icons instead?). Now, rinse and repeat UP TO 2 more times (or whatever you decide I guess with vertical real estate perhaps you could pull up to the most recent 5 release tags, add the 5 buttons and split them horizontally depending on assets of that release tag. Make more sense? I apologize I should have just tried to wireframe this up as a quick mockup to show you the vision but hopefully this explanation is a bit better. It's pretty much taking almost exactly the new dropdown you created for rawlinks and tacking it below the main ZIP with the main diff having to deal with the darn release tag ASSETS as a new level. Not sure my vision is best approach but hey - nobody's done anything like it yet and I'd already put serious $ down that this script is going to wind up being so popular that it tops your user lists, and that GH begins borrowing for future site changes. :) EDIT: Hence why my initial stab at the name was more of "Git-Releases" vs "Git-Zip" since it would also be adding the very much missing front-page repo links to actual binary installers and other release assets that I have always been blown away is totally void from the main GH repo page. 😉 |
|
Hmm, I'm not sure how well that would work. If you look at GitHub's hub releases, you'll see they have 11 different downloadable files. Luckily, the old API provides those link urls in the
As for listing all of the assets in the tags tab, that seems doable. In both instances, I'd use the same method as the raw links userscript - include an empty dropdown that populates when you interact with it. |
|
Doh! Not sure where my brain was but yes a dropdown absolutely is the logical choice and looks awesome in your example! The one thing I would ask you to (re)consider that I just noticed using the enhanced new ZIP download on a repo was that one previously-used naming element seems to have actually gotten dropped with all the new additions - being the [BRANCH]! Don't you agree that needs to be put back in? I'll run through a quick breakdown to demonstrate. I just happen to have open the ConEmu repo so I'll use as example:
Go there, disable this new userscript, and download the repo zip and the browser (via Content-Disposition header) will suggest filename of:
Now switch to daily branch and click zip again and receive:
However, enable this script and do the same and you get: Master: Given today's path length max allowances, I see no issue with you adding back branch name. I do see the difference when the versioning plus commit is in fact reflected, but hopefully you see my point there is now no quick visual indicator which branch it came from and you can of course have commits rolled into different branches/releases. In fact, removing the branch in cases where they have chosen release titles like the one used here "preview", you can see how it can be pretty confusing without branch in the name. If I had to pick, I would simply add it back in right where it originally was - after the repo name so: Master: IMO at that point, you have achieved absolute naming perfection, and frankly how it always should have been. |
|
Forgot to add this to my to-do list... I'll get to this soon! |
|
Hey @Mottie I just saw the available update to this "Github Download Zip" script and installed it, and despite it working as before in the commits links, for some reason now on the most important (to me) main repo page download button ZIP, it no longer is adding the icon nor changing the link so the default |
|
Bah, I forgot about this enhancement again 😿 |
|
I looked at the latest request and I don't think it's possible. This userscript is essentially pointing to urls of existing end-points, and there isn't any way I can think of to intercept and rename the downloaded file. As for creating a select, I haven't gotten around to it yet. Sorry 😞 |
|
Finally added! |
Hey Rob!
So I spent some time digging through the darned GH site code (my head hurts now) and after taking your rawlinks script as a guide (JS not my primary lang) began and fairly quickly now feeling defeated on one of those things I've been putting off it seems forever that seems to still be missing from any available GH enhancements out there.
From talking to others I know I'm not the only one that frequently (despite yes, using official Git) either prior to deciding to do an official local clone to work on, or simply for backup/analysis of my or some other repo, utilizing the GH web
Clone or Download \ Download Zipbutton. Be it on different branches, etc.So, now to where I had always felt there was room for a "wouldn't that be cool" that over the years has become "I'm really tired of having to...." is:
Clicking on the
Download Zipenhanced to append thecommit-tease-sha(short-sha) element text at the end of the target filename. Today, re-saving the repo only results in"Repo-master(1).zip","Repo-master(2).zip"so what an excellent idea to instead, through userscript magic, make it automatically save/suggest as"Repo-master(07f668c)","Repo-master(210f04)"since personally, that is now what I wind up having to do by hand to better identify the downloaded version(s).This itself introduces a challenge I had not considered until diving in - when you look at the HREF the zip is named based on the branch (
master.zip/develop.zip/etc.) however is really only a fallback because the header returned hands the browser (if it's listening) theContent-Disposition: attachmentheader at which time the browser suggests/defaults to in GH case:<reponame>-<branchname>.zip. This is why if you do a standard wget or curl you getmaster-zip, and if you open Chrome and click you getRepo-master.zip. So, there is that challenge to deal with and I have seen decent examples of utilizing the header inXMLHttpRequest(), but still hitting a brick wall at the design phase as to the best approach.Clicking on the same
Download Zipalso enhanced to appending 3 new list elements below the (hopefully enhanced) ZIP file download button. Perform an API lookahead (this is where the rawlinks I thought could be helpful since I eventually realized it needs to do basically the exact same thing you did there but in repo/releases) to the releases page, pull UP TO the first three (3) most recent (let's say strictly the ZIP files for simplicity). I did come up with nice jquery code right before it occurred I should instead be using the API and I had totally wasted my time :(.I really really cannot believe nobody has written even just the releases one since the binary releases are so commonly downloaded and most are only interested in the more current and want to perhaps see the comparison to the prior release for possible rollback. If this is perhaps something you would ever want to work on I will certainly share the (apparently little) I have determined (I have narrowed down I believe some of the key element selector/paths etc.). I just recall when we discussed the rawlinks how fast you churned that out, and being that much of these two enhancements (I think) is already just perhaps a regurgitation/rework of that same script maybe you'd look and think this would be just as easy for you. :)
TIA!
The text was updated successfully, but these errors were encountered: