[Proposal] Run ansible-linter in early CI stage

[AntoineDupre]

This PR is a proposal to move CI Q&A related checks (ansible-lint) before spawning functionnal tests environements for each distributions.

Current Situation

• Q&A (linter) checks are executed inside each distribution test environment.
• As we currently test 4 distributions, quality checks are executed four times.
• Distribution tests are advanced, long-running, and resource-intensive.
• These distribution tests rely on their own dedicated repository.
• Linter checks, however, are specific to the Ansible repository where this CI runs.
• CI Functional tests for the overall Seapath project are coupled with repository-specific quality checks.

This setup leads to:

• Redundant execution of linter checks
• Unnecessary provisioning of costly environments when basic quality rules fail
• Pollution of specialized test environments with checks that could run in a standard CI environment
• Suboptimal resource utilization

Proposed Changes
Move linter execution to an early CI stage:

• Execute these checks in a standard CI environment.
• Fail fast if project quality rules are not respected.
• Only trigger advanced distribution tests if Q&A checks pass.

The goal is to clearly separates Repository Quality Tests (ansible-linter specific to ansible repository) from functional distribution tests.

In the future, the publication of test reports and the management of artifacts could also be treated as dedicated post-test steps.

[eroussy]

Seems great, just one question

In this implementation, we have multiple workflows, that each contains one job
Would it be simpler to have multiple jobs called from one workflow ?
And have each distrubution tests using the needs: [ansible-lint] ?
For example here : https://github.com/geisa/conformance/blob/4e20c7bd2bf6b30f3ae40e45529ae9ab89c9dc96/.github/workflows/ci-conformance.yml

That being said, it is great to keep

• one workflow file per distribution check.
• the workflow dispatch on each distribution check.
  So I don't know if it is possible to do that, it would just seems more natural

[eroussy]

Also, the naming is a bit broken. Now we have CI/ci-debian/CI so the last "CI" is too much
That's not an important issue, but it points toward the usage of jobs instead of workflows IMO

[eroussy]

Also, it seems not possible to stop only one distribution test and relaunch it (ex: stopping/relaunching only the debian CI)

[AntoineDupre]

I think the workflow-by-distribution approach still makes sense for a few reasons:

• Each distribution can be triggered independently via workflow_dispatch
• Weekly workflows can easily reuse the same distro workflows
• Clear separation of concerns (one file per distribution)

The ci-*.yml distribution files should be seen as reusable tasks, not as entry points dedicated only to PR validation. They can be triggered:

• From PR CI
• From scheduled workflows
• Manually
• Potentially from other workflows in the future

Because of that, I think we should clearly separate:

• CI orchestration
• Q&A checks (ansible-lint, etc.)
• Distribution system tests

Concretely, I would suggest:

• Turning ci-ansible-lint.yml into a pure Q&A workflow (like qa.yml)
• Introducing a top-level ci.yml acting as the orchestrator
  • It defines the needs: ansible-lint
  • It invokes the distro workflows via uses:

This way:

• The orchestration logic lives in one place
• Distro workflows remain generic and reusable
• The dependency (needs) is defined at the orchestration level, not inside each distribution workflow

Jobs in distribution files should probably have a more specific name instead of CI, like System Test or Integration Test, since they can be triggered from different workflows and contexts.

---

Regarding re-running jobs:
You can re-run failed jobs only.
You cannot stop a single running job without cancelling the whole workflow.

I can not really figure out what is the concrete use case where you would need to stop and reschedule a single job?

[eroussy]

Yes, I love the idea of introducing a top-level ci.yml orchestrator. Can you do that ?
The rest of the PR seems fine to me (including permissions)

[eroussy]

LGTM

Also @insatomcat I see that we are low on space on the debian ci runner, could you clean it up a bit or add space to the VM ?

[eroussy]

Merging that now, we should take care of

• Changing the required CI step for merge (I do that)
• verify that the weekly CI launch correctly on next week end