Giters

userdocs / qbittorrent-nox-static

A bash script which builds a fully static qbittorent-nox binary with current dependencies to use on any Linux OS

Home Page:https://userdocs.github.io/qbittorrent-nox-static

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Standard tag name for one at least one of the builds

onedr0p opened this issue · comments

commented

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. 🙏🏼

commented

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

release-4.4.0_v2.0.5
release-4.4.0_v2.0.6
release-4.4.0_v2.0.7

before they release

release-4.4.1

The format to parse is

{qbittorrent tag}_{libtorrent tag}

Parsing these should not be an issue as the tags are not modified.

https://github.com/qbittorrent/qBittorrent/tags
https://github.com/arvidn/libtorrent/tags

commented

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 VERSION file in the same directory. Any time that VERSION changes, github workflows will build the image passing the contents of the version file to the docker build as a arg. This is done this way to ensure we get the exact version of an app and puts semantic tags on our docker images. We never want to :latest.

Maybe there could be logic written to tag release-4.4.0 with always the latest libtorrent version while the rest get the libtorrent version in the release name? I'm not at all picky on which libtorrent version gets the release-4.4.0 tag.

commented

No thoughts to my response, you just closed it? Guess I'll fork this and do it myself. Thanks!

commented

I already gave my thoughts.

#73 (comment)

commented

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.

commented

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.

commented

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.

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 jq query I've pointed out.

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 $version, for a certain arch to download the binary?

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.

commented

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')

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

release-4.4.0_v2.0.5

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.

commented

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.

commented

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.

commented

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

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.