cdk-pipelines-github icon indicating copy to clipboard operation
cdk-pipelines-github copied to clipboard

Set `defaults` for GHA job

Open danieljamesscott opened this issue 2 years ago • 2 comments

I would like to run the pipeline actions in a working directory under my repository root. e.g. My CDK app files are in ./cdk/. I currently do this using:

  test:
    name: Test
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: cdk

Is there a way to pass a defaults block into the pipeline config?

danieljamesscott avatar Aug 15 '22 10:08 danieljamesscott

You can currently add job level defaults to any JobStep via the defaults property: https://github.com/cdklabs/cdk-pipelines-github/blob/ad882b9d2e311c427d3a91a3236c0af5c6999546/src/workflows-model.ts#L90

There is also a JobSettings property on the GitHubWorkflow construct that can potentially be extended to add things to all jobs if necessary. Where are you trying to pass a defaults block?

As always, these issues demonstrate to me the need for escape hatches as the next thing we support. Then, no one will be truly blocked and can patch anything they want in the workflow on their own. I see you already have some ideas on this issue -- thanks! I feel like that is the most important next thing to add to this library. When I have the time, that's something I want to add.

kaizencc avatar Aug 29 '22 21:08 kaizencc

You can currently add job level defaults to any JobStep via the defaults property:

https://github.com/cdklabs/cdk-pipelines-github/blob/ad882b9d2e311c427d3a91a3236c0af5c6999546/src/workflows-model.ts#L90

There is also a JobSettings property on the GitHubWorkflow construct that can potentially be extended to add things to all jobs if necessary. Where are you trying to pass a defaults block?

JobStep may work for my use case, but I was trying to pass it for the whole job: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun

As always, these issues demonstrate to me the need for escape hatches as the next thing we support. Then, no one will be truly blocked and can patch anything they want in the workflow on their own. I see you already have some ideas on this issue -- thanks! I feel like that is the most important next thing to add to this library. When I have the time, that's something I want to add.

Yep, that would solve a lot of the issues I'm seeing. Thanks!

danieljamesscott avatar Sep 05 '22 11:09 danieljamesscott