All actions are pulled using the version hash, versions are handled by
dependabot, and we'll have control over which actions get updated.
Replaces Trivy scanner with Docker Scout, we have recently begun analyzing the
images there, and the action will keep us in sync about the problems on GHCS
dashboard.
Integration / Python 3.10 (push) Has been cancelled
Integration / Python 3.11 (push) Has been cancelled
Integration / Python 3.12 (push) Has been cancelled
Integration / Python 3.13 (push) Has been cancelled
Integration / Theme (push) Has been cancelled
Documentation / Release (push) Has been cancelled
Integration / Python 3.9 (push) Has been cancelled
checker.yml
1. The checker is not yet of sufficient quality to allow the results of the
check to be evaluated / we do not evaluate them ourselves.
2. The checker sends hundreds of requests to the search engines and causes
problems there / we either overload small providers or we train their bot
defenses to use the SearXNG signature.
documentation.yml
Building the documentation and deploying it on GH-docs of a clones (GH forks) is
generally not desirable either --> We have >2k clones, but we only need one
up-to-date documentation and that is the one from the master branch of the
searxng/searxng repo.
If search engines like Google start linking to the documentation in the clones,
SearXNG users may no longer find the original documentation or be lost in the
flood of options.
Related:
- https://github.com/searxng/searxng/issues/4847
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
`checker.yml` and `integration.yml` are the only workflows that are currently safe to be executed simultaneously, the others present a risk that the order of completion may not be expected. The ones that are chained from `integration.yml` can be called as many times as `integration.yml` workflows are running at that moment, the same with the trigger "workflow_dispatch".
This can be fatal for workflows like `container.yml` that use a centralized cache to store and load the candidate images in a common tag called "searxng-<arch>".
* For example, a `container.yml` workflow is executed after being chained from `integration.yml` (called "~1"), and seconds later it may be triggered again because another PR merged some breaking changes (called "~2"). While "~1" has already passed the test job successfully and is about to start the release job, "~2" finishes building the container and overwrites the references on the common tag. When "~1" in the release job loads the images using the common tag, it will load the container of "~2" instead of "~1" having skipped the whole test job process.
The example is only set for the container workflow, but the other workflows might occur in a similar way.
Integration / Update translations branch (push) Blocked by required conditions
Integration / Docker (push) Blocked by required conditions
Instead of executing the workflow after integration.yml completes correctly, let's run this workflow parallel to integration.yml restoring the original behaviour.
documentation.yml will run after integration.yml COMPLETES successfully (will
defer anything depending on integration.yml until heavy loads like container
building are moved to separate workflows) and in master branch.
Style changes, cleanup and improved integration with CI by leveraging the use of
shared cache between all workflows (not functional until all workflows have been
refactored).
