Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set defaults for GHA job #299

Open
danieljamesscott opened this issue Aug 15, 2022 · 2 comments
Open

Set defaults for GHA job #299

danieljamesscott opened this issue Aug 15, 2022 · 2 comments

Comments

@danieljamesscott
Copy link

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
Copy link
Contributor

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

readonly defaults?: JobDefaults;

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
Copy link
Author

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

readonly defaults?: JobDefaults;

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants