search

cdklabs / cdk-pipelines-github

Apache License 2.0
343 stars 37 forks source link

Set `defaults` for GHA job #299

Open danieljamesscott opened 2 years ago

danieljamesscott commented 2 years ago

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?

kaizencc commented 2 years ago

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.

danieljamesscott commented 2 years ago

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!