[1/3] githib-releases: add a class that consolidates version checks

github has recently changed how the releases page is structured:
the tarballs are no longer listed directly, but are included
via separate 'fragment' URIs. For now, we can change the check
to match against the release tags.

This also establishes a common base URI to use for both
fetching and checking the latest version.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/classes-recipe/github-releases.bbclass | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 meta/classes-recipe/github-releases.bbclass

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Alexander Kanavin
> Sent: den 27 september 2022 14:09
> To: openembedded-core@lists.openembedded.org
> Cc: Alexander Kanavin <alex@linutronix.de>
> Subject: [OE-core] [PATCH 1/3] githib-releases: add a class that consolidates version checks

Change "githib" to "github".

> 
> github has recently changed how the releases page is structured:
> the tarballs are no longer listed directly, but are included
> via separate 'fragment' URIs. For now, we can change the check
> to match against the release tags.
> 
> This also establishes a common base URI to use for both
> fetching and checking the latest version.
> 
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>  meta/classes-recipe/github-releases.bbclass | 3 +++
>  1 file changed, 3 insertions(+)
>  create mode 100644 meta/classes-recipe/github-releases.bbclass
> 
> diff --git a/meta/classes-recipe/github-releases.bbclass b/meta/classes-recipe/github-releases.bbclass
> new file mode 100644
> index 0000000000..ed83b83731
> --- /dev/null
> +++ b/meta/classes-recipe/github-releases.bbclass
> @@ -0,0 +1,3 @@
> +GITHUB_BASE_URI ?= "https://github.com/${BPN}/${BPN}/releases/"

Is that really useful? It cannot be many recipes where the owner 
part of the URL actually matches ${BPN}? Wouldn't it make more 
sense to instead use something like:

GITHUB_OWNER ?= "${BPN}"
GITHUB_NAME ?= "${BPN}"
GITHUB_BASE_URI ?= "https://github.com/${GITHUB_OWNER}/${GITHUB_NAME}/releases/"

That way it is more evident in the recipe when GITHUB_OWNER and/or 
GITHUB_NAME is set, rather than the entire GITHUB_BASE_URI being 
redefined.

> +UPSTREAM_CHECK_URI ?= "${GITHUB_BASE_URI}"
> +UPSTREAM_CHECK_REGEX ?= "releases/tag/v?(?P<pver>\d+(\.\d+)+)"
> --
> 2.30.2

//Peter

On Tue, 27 Sept 2022 at 16:17, Peter Kjellerstedt
<peter.kjellerstedt@axis.com> wrote:

> Is that really useful? It cannot be many recipes where the owner
> part of the URL actually matches ${BPN}? Wouldn't it make more
> sense to instead use something like:
>
> GITHUB_OWNER ?= "${BPN}"
> GITHUB_NAME ?= "${BPN}"
> GITHUB_BASE_URI ?= "https://github.com/${GITHUB_OWNER}/${GITHUB_NAME}/releases/"
>
> That way it is more evident in the recipe when GITHUB_OWNER and/or
> GITHUB_NAME is set, rather than the entire GITHUB_BASE_URI being
> redefined.

I ran some stats on the recipes in core that have been transitioned to
the class:

total: 39
same owner/same name as the recipe, no override of GITHUB_BASE_URI: 11
different owner/same name as the recipe: 14
different owner/different name as the recipe: 14

I would rather avoid adding abstractions and reducing readability by
defining even more variables, perhaps recipes that use different
owner/same name can use:
GITHUB_BASE_URI = "https://github.com/custom-owner/${BPN}/releases/"
(some already do, but not all). I also find it very useful to be able
to click on URIs on recipes, and don't like having to copy-paste-edit
bits of it
to get where I want in the browser :)

In any case, the major point here is to fix upstream version checks so
that AUH can continue do its work. A minor point is to define the base
uri (the part up to 'releases') only once, or use a default where
possible.

Alex