Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
`hooks[].command` should be equivalent to `commands[].command` #730
Comments
|
Why not allow for both variants? Add If that gets too complex, I would prefer keeping the |
|
@mgruener That sounds like a smart way of allowing both. Should be straight forward to implement: @FabianKramm What do you think? |
|
Yes sounds good to me |
|
As a variant of what @LukasGentele suggests, it could be done using docker's convention: if command is a list, then interpret as binary w/ arguments; if it is a string, then treat it as something to be run in a shell. |
Is your feature request related to a problem?
Currently,
commands[].commandallows a string with bash-like syntax that is interpreted like a shell script.hooks[].command, however, expects a single binary and allows to provide args viahooks[].args. This is not intuitive to understand.Which solution do you suggest?
hooks[].commandshould be equivalent tocommands[].commandand expect a command andhooks[].argsshould be deprecated. Ifhooks[].argsis specified, there could be a fallback to the current behavior which prevents a breaking change but allowshooks[].commandto adapt the new behavior.Which alternative solutions exist?
Additional context
/kind feature