Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Better flow control: Ability to use Waves, set `if` on individual stages/steps

Aperta
  • Qualcosa non va?
#376 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

  • #377 di @giseburt — chiusa senza merge

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
github-actions, typescript
Ambito
ci-cd, devops

Direzione di ricerca

Inizia dalla discussione in #365 e dagli entry point proposti GitHubWorkflow, GitHubStage e addWave, quindi esamina la PR pronta menzionata nell’issue. Verifica che il workflow di esempio produca i quattro job descritti, incluse le espressioni if a livello di stage e le dipendenze basate sulle wave; il lavoro è completato quando i job e le dipendenze generati corrispondono al comportamento indicato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

This continues from the discussion in #365 with the if control.

Looking at the docs for jobs.<job_id>.if, it appears that:

  1. The if statement, if present, can allow a step to build if dependent steps (in jobs.<job_id>.needs) fail, skip, or are cancelled.
  2. The if statement, if omitted, is the same as if: success() [^1]
  3. The if expression options that allow bypassing failure are: (Same reference.)
    • always() - ignores failure AND cancellation
    • failure() - ONLY on failure
    • cancelled() - ONLY if the workflow was cancelled
    • success() || failure() - unlike always() this allows cancellation of a step
  4. If a previous step is skipped then the if skips dependent steps unless one of the above expressions is added, known issue: actions/runner#491
    • The best proposed solution for NOT skipping dependent steps, but also not running the if there's been a failure:
        if: |
      always() &&
      !contains(needs.*.result, 'failure') &&
      !contains(needs.*.result, 'cancelled') &&
      <ACTUAL TEST INTENDED HERE>
  5. Closely related is jobs.<job_id>.continue-on-error - which allows a job to act as if it succeeds even when it fails, making a job that cannot fail

1, 2, and 4 means that we only need the if statement on the build phase, and can skip if statements on publish steps. Depending on how 4 gets "fixed" either an if will need to be added with !(failure() || cancelled()) (As this workflow run demonstrates).

I see no value on adding (customized) if statements on publish jobs in the absence of a way to correlate the asset being deployed with some tangible asset name. Even then the value is dubious, since it'll likely invalidate the deployment since asset publish steps are shared by deployment steps that use those assets.

In a closely related issue, needs is used to handle dependencies, which the only way to make a stage NOT depend on another stage is with pipeline.addWave(), but that doesn't support GitHub options such as this if in the current code.

In the PR i have ready, this code works as expected (explained more below):

    const pipeline = new GitHubWorkflow(app, 'Pipeline', {
      workflowPath: `${dir}/.github/workflows/deploy.yml`,
      synth: new ShellStep('Build', {
        installCommands: ['yarn'],
        commands: ['yarn build'],
      }),
    });

    const stageA = new GitHubStage(app, 'MyStageA', {
      env: { account: '111111111111', region: 'us-east-1' },
      jobSettings: {
        if: "success() && contains(github.event.issue.labels.*.name, 'deployToA')",
      },
    });

    new Stack(stageA, 'MyStackA');

    const stageB = new GitHubStage(app, 'MyStageB', {
      env: { account: '12345678901', region: 'us-east-1' },
      jobSettings: {
        if: "success() && contains(github.event.issue.labels.*.name, 'deployToB')",
      },
    });

    new Stack(stageB, 'MyStackB');

    // Make a wave to have the stages be parallel (not depend on each other)
    const wave = pipeline.addWave('MyWave');
    wave.addStage(stageA);
    wave.addStage(stageB);

This makes four jobs:

  • Build-Build - with if set
  • Assets-FileAsset1 - needs Build-Build but doesn't have if set otherwise
  • MyWave-MyStageA-MyStackA-Deploy - needs Build-Build and Assets-FileAsset1 and has the correct if set
  • MyWave-MyStageB-MyStackB-Deploy - also needs Build-Build and Assets-FileAsset1 and has the correct if set
    • If it were pipeline.addStage(stageA); and pipeline.addStage(stageB); then there would be an additional needs value of MyWave-MyStageA-MyStackA-Deploy

Obviously there's a new construct GitHubStage, and a new GitHubWorkflow.addWave(). We can discuss technical details in the PR about how these work and if we want to maintain those names, etc.

[^1]: According to the docs here:
> You can use the following status check functions as expressions in if conditionals. A default status check of success() is applied unless you include one of these functions.

Lingua principale
TypeScript
Stelle
385
Fork
45
Merge medio
1g 52m
PR unite (30g)
4

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cdklabs/cdk-pipelines-github

Tutte le issue di cdklabs/cdk-pipelines-github

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.