added scripts for outdated appcasts #18237
Conversation
vitorgalvao
added
awaiting maintainer feedback
|
|
||
| http_status="$(curl "${curl_flags[@]}" --head --write-out '%{http_code}' "${appcast_url}" -o '/dev/null')" | ||
|
|
||
| [[ "${http_status}" == 200 ]] && echo 'true' || echo 'false' |
There was a problem hiding this comment.
You could leave off the echos here and just return [[ "${http_status}" == 200 ]].
|
As a small note, you may notice the |
|
@vitorgalvao We could always use the gitter chatroom (maintainers have their own room), but I'm not sure if everyone uses it. |
|
@adidalal I’m fine with that. |
|
Just a note:
For casks with unversioned urls this might no be often enough (as they are most likely not only outdated, but broken when the appcast changes). Btw nice scripts 👍 Regarding a bot server: I've successfully used |
|
Ran through it once today (for Definitely easier than manually going through things, no doubt! 👍 for scripting. A question: How do you get .atom/feeds to open up in sublime text/atom/$EDITOR - I had to manually wget/open in sublime, which was not fun. A tip: after a huge bunch of merges, do |
So you interrupted it?
But are you going through the issues, though? Why? With the
I can certainly add the homepage to the issue if you want. I’m just trying to figure out a solution that would fit you better. If not and you still want the homepage in the opened issue, say so and I’ll add it.
What do you suggest? I haven’t given much though to it and don’t really care. The message is just there as a way to justify why the issue was closed, in case a user finds it. I’m certainly open to changing it.
They open in Chrome by default, for me Seems to not work in Safari, though, now that I tried it. Reading that atom file is harder than looking at the releases page, anyway, so I was already thinking of simply opening the releases page instead of the appcast when it detects it’s a github released URL, so I’ll likely just do that and solve your issue in the process.
Will do. |
Actually, can I get a bit of reading material on why those commands are the best (I was reading on them all to find out how they exactly work)? Apart from this StackOverflow answer (with a relatively low amount of up votes), I don’t see that sequence anywhere else, and it seems that From what I can find, it seems |
|
I open the issues to get the latest version. I use Safari, so the app cast doesn't open up automatically. I then need to wget the app cast and open in sublime. For my ease of use I commented in the issue, so that I have that when cask repair asks. Putting the url/github releases would be super useful, at least for me. If you can envision a better workflow, though, let me know. "Resolved in PR #____" could work, but doesn't really matter, as you said. I had that sequence in my .gitconfig and can't source it, so I'm assuming just gc is fine. (Will also update my dotfiles accordingly) |
Done. Also, the merge script now runs |
added scripts for outdated appcasts
adidalal
removed
the
awaiting maintainer feedback
To run these, simply do it. It doesn’t matter where, they take care of everything. How they work:
find_outdated_appcasts:appcast, verify it.outdated appcastlabel.Snippet of output:
fix_outdated_appcasts:outdated appcastand loop through them.appcastin the browser (or whatever default app).cask-repair(it willblind-submit).merge_outdated_appcasts:outdated appcastand loop through them.fastmergeit.outdated appcast.cask-repair --delete-branches.Snippet of output:
You might notice
find_outdated_appcastsoutputs full URLs (as doesfix_outdated_appcasts, throughcask-repair), whilemerge_outdated_appcasts(throughfastmerge) does not. However, that will indeed happen if there’s an error. So opening issues and errors (i.e. when you might want to directly go to the issue) produces the full link, while closing them successfully does not. Showing a bunch of links in a row (i.e. a lot of merging successes) is confusing and makes it harder for the eyes to parse, but when spaced out (occasional opening of issues and PR submissions) calls attention to them. Quick tip to iTerm2 users, ⌘+click on a URL will open it.As for the duplication between the scripts, this is one of those cases where they all do similar things but require minute differences in various areas, and jumbling them all together, at least in this initial step, would cause more confusion than what is worth.
There may also be some doubts regarding interacting directly with upstream instead of using forks, and again this is one of those cases of “first lets see if we can get it to work at all”. Doing it this way, at least initially, is easier for various reasons, including not having to worry if the maintainer has all the repos tapped/cloned and not having to worry about the naming they gave to their branches.
The final consideration is when and how to run these. I’ve been doing it so successfully for a while, but from the moment any maintainer can do it, we risk stepping on toes. I’ve been thinking of systems where the script would assign the issue to who ran it, and only run if issues were assigned to you, hence mitigating possible clashes, but all solutions require a lot of web requests, slow down operations considerably, and are convoluted. Easiest way I can think is: whoever ran the
findscript commits to running the other two that same day. That way, one person at a time is responsible.Now, who to run them and when? Initially I thought about having a bot run both the
findandmergescripts regularly (once or twice a week), but there are some considerations. Although I do have a server I could employ for this, it’s shared, and I’m not sure we should trust it with such responsibility1. Also, having the bot open issues when there’s no one to run thefixscript soon after leaves us with a mess of issues.So if we decide a human is to run all three scripts, we need a way to let others know when we do so, to avoid stumbling on each other.
Until we come up with a system to do so (suggestions very welcome), I don’t mind being the one to do it. I’m guessing some of you might be curious to try them at least once before, though, so if you are, reply to this issue (so others know not to run the script as well) and go for it.
1 Yes, it is git and we can reverse things, but I’m more worried about malicious commits we fail to catch. Unfortunately, there’s no way in Github to have a maintainer that can only handle issues (we would need the bot to be a maintainer to label issues). We could forego the labeling mechanic entirely and have the bot with no permissions just open issues with a certain name we can grab, but that is prone to errors.