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 custom default shell #318

Open
eine opened this issue Jan 21, 2020 · 3 comments
Open

Set custom default shell #318

eine opened this issue Jan 21, 2020 · 3 comments
Labels
core enhancement New feature or request

Comments

@eine
Copy link

eine commented Jan 21, 2020

Coming from actions/runner#240

It'd be useful to have a function in the toolkit core which allows to change the default shell for all the following steps in a job. Another solution is to allow to set shell at job level (as it is supported for env). However, I think that supporting it in the toolkit would still be useful.

/cc @dakale

@eine eine added the enhancement New feature or request label Jan 21, 2020
@maximveksler
Copy link

maximveksler commented Mar 13, 2020

Running on windows, it would be nice to set the default shell for all steps to bash.

@thboop
Copy link
Collaborator

thboop commented Mar 13, 2020

For workflow authors not using the default shell, it is fairly verbose having to specify shell: on every run step.

Since this primarily impacts workflow authors rather than action authors, I think this makes more sense as a yaml feature than a toolkit/runner command.

Ideally, at a job level we could provide an option to change the default shell for all steps in that job (but they could still be overwritten if you provide a shell on that step).

I've reached out to the time responsible for that work and they are currently evaluating that feature!

However, I think that supporting it in the toolkit would still be useful.

@eine , Is there a scenario you have in mind that would not be covered by the yaml feature outlined above?

I'm concerned that actions changing the default shell may result in a confusing user experience for those who don't understand why their default shell has changed halfway through a job.

@eine
Copy link
Author

eine commented Mar 13, 2020

@thboop, the scenario would a shell that is contributed by an action, which is a step. Hence, setting it at the job level would not work, because the shell is not available when the first steps in the job are evaluated (until the action that contributes the shell is executed).

Currently, since MSYS2 is not available yet, this is the use case of setup-msys2. However, I believe that it can have more uses. I agree that arbitrary actions changing the default shell can be confusing. But it should not if the purpose of the actions is precisely to provide a custom shell.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants