Since e8ee4228 (CI: remove deletion tasks of 'packet' VMs, 2024-09-13),
our tests appears to not be flakey anymore.
The current retry slow down the testing feedback on pull request.

Since it's not needed anymore, don't retry and fail fast.

Run CI without the sample inventory

Sometimes the change done by pre-commit are not obvious, this should
help.

Overhaul of the python hashes updater

* Cleanup not in k-sigs members OWNERS

Signed-off-by: ChengHao Yang <17496418+tico88612@users.noreply.github.com>

* Cleanup inactive members on Kubespray

Signed-off-by: ChengHao Yang <17496418+tico88612@users.noreply.github.com>

---------

Signed-off-by: ChengHao Yang <17496418+tico88612@users.noreply.github.com>

* [kubernetes] Support Kubernetes v1.32.0

* add workaround for RHEL8

Signed-off-by: Kay Yan <kay.yan@daocloud.io>

---------

Signed-off-by: Kay Yan <kay.yan@daocloud.io>
Co-authored-by: Mohamed Zaian <mohamedzaian@gmail.com>

By separating logic from data, we should make it easier to add new
components.

* Contrib: upload2artifactory.py

Signed-off-by: Bas Meijer <bas.meijer@enexis.nl>

* Pythonic

Signed-off-by: Bas Meijer <bas.meijer@enexis.nl>

* Suggested

Co-authored-by: Arthur Outhenin-Chalandre <arthur@cri.epita.fr>

* upload2artifactory.py documentation.

---------

Signed-off-by: Bas Meijer <bas.meijer@enexis.nl>
Co-authored-by: Arthur Outhenin-Chalandre <arthur@cri.epita.fr>

Co-authored-by: nvalembois <nvalembois@live.com>

- remove unused parts in the response
- clarify variables names

This is handy when some component releases is buggy (missing file at the
download links) to not block everything else.

Move the filtering up the stack so we don't have to do it multiples
times.

This means the update-hashes command can be run anywhere in Kubespray
repository without having to figure out the correct path.

Can operate on several branches without the need for backport

Signed-off-by: Kay Yan <kay.yan@daocloud.io>

Gvisor releases, besides only being tags, have some particularities:
- they are of the form yyyymmdd.p -> this get interpreted as a yaml
  float, so we need to explicitely convert to string to make it work.
- there is no semver-like attached to the version numbers, but the API
  (= OCI container runtime interface) is expected to be stable (see
  linked discussion)
- some older tags don't have hashs for some archs

Link: https://groups.google.com/g/gvisor-users/c/SxMeHt0Yb6Y/m/Xtv7seULCAAJ

Gvisor is the only one of our deployed components which use tags instead
of proper releases. So the tags scraping support will, for now, cater to
gvisor particularities, notably in the tag name format and the fact that
some older releases don't have the same URL scheme.

(the url should use `alt_arch` instead of `arch` for those)

Also, always raise even for 404 not found (should not happen now that
we'll use GraphQL to find the exact set of versions)

We're only interested in new patch releases for auto-update.

Containerd use the same repository for releases of it's gRPC API (which
we are not interested in).
Conveniently, those releases have tags which are not valid version
number (being prefixed with 'api/').

This could also be potentially useful for similar cases.
The risk of missing releases because of this are low, since it would
require that a project issue a new release with an invalid format, then
switch back to the previous format (or we miss the fact it's not
updating for a long period of time).

We obtain the set of version from Github, then for each component we do
a set comparison to determine which versions we don't have.

The Github graphQL API needs IDs for querying a variable array of
repository.

Use a dict for components instead of an array of url and record the
corresponding node ID for each component (there are duplicates because
some binaries are provided by the same project/repository).