Standard tag name for one at least one of the builds about qbittorrent-nox-static HOT 13 CLOSED

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.

from qbittorrent-nox-static.

It's done in the matrix build action

https://github.com/userdocs/qbittorrent-nox-static/blob/master/.github/workflows/matrix_multi_build_and_release.yml#L28
https://github.com/userdocs/qbittorrent-nox-static/blob/master/.github/workflows/matrix_multi_build_and_release.yml#L31
https://github.com/userdocs/qbittorrent-nox-static/blob/master/.github/workflows/matrix_multi_build_and_release.yml#L121

https://github.com/ncipollo/release-action

from qbittorrent-nox-static.

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

from qbittorrent-nox-static.

Also this https://github.com/k8s-at-home/container-images/blob/ad206320232ad918ea039105dfaa14504f9d7e3c/apps/qbittorrent/Dockerfile#L29L30

Why you are doing this is strange to me when the readme to get the latest versions does this

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

from qbittorrent-nox-static.

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.

from qbittorrent-nox-static.

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

from qbittorrent-nox-static.

I already gave my thoughts.

#73 (comment)

from qbittorrent-nox-static.

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.

from qbittorrent-nox-static.

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.

from qbittorrent-nox-static.

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.

from qbittorrent-nox-static.

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.

from qbittorrent-nox-static.

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.

from qbittorrent-nox-static.

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.

from qbittorrent-nox-static.