Adjust pipeline tasks granularity

[pnpavlov]

Proposal 1: Adjust pipeline tasks granularity

Findings

As a garden linux maintainer, I want fast and targeted feedback on the code that I am comiting. The ability to run a subset of tests tasks in granular way would help me getting faster feedback.

Proposal

I would like to enable a way of running certain parts of the nightly workflow less intertwined and with more flexible input parameters. The input parameters decide which jobs do run with a certain subset of settings.

• input parameters to nightly (or any similar workflow)
  • version --> version to built (parameter already exists)
  • jobs --> run only certain jobs
  • build
  • tests --> can be run without build phase by passing an already existing version
  • upload
  • container
  • arch --> run only certain architecture
  • platform --> run only for certain platforms (e.g. GCP)
  • use_kms --> do (not) run jobs that need KMS secrets
  • modifier --> image modifiert (e.g. "-gardener_prod")

[fwilhe]

Not sure about this, I did not often feel the need to run a subset of the platform tests.

I think that keeping an overview of our github workflows is pretty hard, we have a lot of workflows that partly call each other, so being informed about which tests we have is not trivial.

If this proposal does not make that situation worse by adding more complexity, then it's fine with me, but honestly I would prioritise simplification over more flexible invocation.

[yeoldegrove]

@fwilhe Thanks for the feedback about "do we really need this" ;)

I think we need to document anyways which workflows run for which purpose better. I am totally on your side that this is hard to understand at the moment.

One approach to not make the default nightly workflow even more complex would be not touching nightly in regards of the input parameters but touch every workflow it calls and that create a workflow called manual that has the ability to define all the input parameters I mentioned.

@fwilhe What do you think about the ability to not run a "subset of the platform tests" but "run platform tests with an existing image", so basically only the "test" job with an certain gardenlinux version as input?

[pnpavlov]

Descision: @yeoldegrove documents the feedback received in the meeting on 23rd Sept. We go forward and execute in October as agreed

[yeoldegrove]

The feedback was:

• Go forward with the approach that was outlined (running certain jobs/arch/platforms independently):
  • running certain jobs/phases of the build without dependencies to other jobs/phases
  • dev workflow already only runs build phase.
  • idea: tests in PRs
  • run a subset of tests based on files changed
  • idea: use labels or comments in PRs to allow access to secrets/environments to run platform tests
  • use autolabeler or manual labels/comments
  • where to pull artifacts/images from e.g. if only running test phase
  • releases --> for released versions
  • github artifacts --> for dev versions
  • s3 --> evaluate