-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standard tag name for one at least one of the builds #73
Comments
I don't think I will change this because it's required to differentiate between build combinations. I build whenever a new libtorrent or qbittorrent is released so it won't work to just use the qbittorrent tag So I could have
before they release
The format to parse is
Parsing these should not be an issue as the tags are not modified. https://github.com/qbittorrent/qBittorrent/tags |
Let me explain that repo a bit more. It's a mono repo to build docker images with upstream semantic version tags. Using github workflows every 4 hours this script gets ran to check for newer versions of an app. The output of that script is saved to the Maybe there could be logic written to tag |
No thoughts to my response, you just closed it? Guess I'll fork this and do it myself. Thanks! |
I already gave my thoughts. |
Yep and you left no response to my comment after that. You do you I guess... thanks, I'm already forking this to make machine to machine communication easier. |
I've looked at what you provided, for example this and all I can see it a failure to use the latest release api effectively. https://api.github.com/repos/userdocs/qbittorrent-nox-static/releases/latest Nothing you have requested cannot be achieved by parsing this url. Aside from it having nothing to do with this project, as an issue or anything really, it's really more of an issue with how you are doing things. I could easily do what you are asking with no requirements to change anything. If you can't see that, I guess you do you. |
The issue maybe my own, but it would be nice to have a clean repeatable process for building Docker images from these static binaries. The release API can only help so much but when you tag things the way you are and don't have a common tag for a specific version it leads to the There's not a better way to grab the most recent version that isn't a pre-release than this: version=$(curl -sX GET "https://api.github.com/repos/userdocs/qbittorrent-nox-static/releases" | jq -r '[.[] | select(.prerelease==false)][0] | .tag_name') Now what if someone wanted to pull an exact tag based on curl -sX GET "https://api.github.com/repos/userdocs/qbittorrent-nox-static/releases" | jq -r --arg version "${VERSION}" '.[] | select(.prerelease==false) | select(.tag_name | startswith("release-\($version)")) | .assets | .[] | select(.browser_download_url | endswith("x86_64-qbittorrent-nox")) | .browser_download_url' All I'm asking for is pretty much a symlink on a single release to make automation easier when building Docker images. It sounds like to much of a ask, so I'll move on. |
You are wrong and I am not sure how many times I have to say this but here is one exmaple: curl -s "https://api.github.com/repos/userdocs/qbittorrent-nox-static/releases/latest" | jq -r '.tag_name' Will return
So just parse it properly. There is only ever one latest release and it will be the latest qbittorrent version built against the latest supported libtorrent. At this point it seems you'd rather justify what you are doing than do it properly. |
Ok cool, that's good to know. My confusion was coming in from the previous releases you have which were all marked as pre-release. You sound like moving forward you only tag latest release of qb and libtorrent as a release, not a pre-release. |
The latest release has always been in the format: Latest version of qbittorrent built against the latest supported version of libtorrent. Which is now qbittorrent 4.4 + libtorrent v2 whereas before it was qbittorrent 4.3 + libtorrent v1.2. Hence the reasons the release and pre-release swapped over to V2 The action will build when either a new qbittorrent or libtorrent version is released so the tagging method cannot/will not be changed. This is how you properly get the tag for the latest release (since the start of the project) curl -s "https://api.github.com/repos/userdocs/qbittorrent-nox-static/releases/latest" | jq -r '.tag_name' This is how you properly get the download correct asset for the latest release https://github.com/userdocs/qbittorrent-nox-static/releases/latest/download/x86_64-qbittorrent-nox
https://github.com/userdocs/qbittorrent-nox-static/releases/latest/download/armhf-qbittorrent-nox
https://github.com/userdocs/qbittorrent-nox-static/releases/latest/download/armv7-qbittorrent-nox
https://github.com/userdocs/qbittorrent-nox-static/releases/latest/download/aarch64-qbittorrent-nox There is no need to change the tags when you can easily get the info you need without it. |
Well that's an interesting way of handling that. I guess people can mark and unmark releases pre-releases as they see fit though. That's not a common pattern to do which also was part of my confusion. |
Hi 馃憢馃徏
It would be great if you could standardize one of these releases (
release-4.4.0_v2.0.5
,release-4.4.0_v1.2.15
) into a tag that does not include the librorrent version in the name.For example, moving forward maybe all builds using libtorrent 2.x could be tagged
release-4.4.0
.The reason I'm bringing this up is that I maintain docker images and the jq-fu to parse the tags is working but not very ideal to maintain moving forward.
See: https://github.com/k8s-at-home/container-images/blob/ad206320232ad918ea039105dfaa14504f9d7e3c/apps/qbittorrent/Dockerfile#L29L30
Thank you so much for building these binaries and releasing them here. 馃檹馃徏
The text was updated successfully, but these errors were encountered: