Replies: 13 comments
-
|
Hi @gzukel - apologies for the delay in getting back to you. This is very good feedback - you may notice that we recently added input types for |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ethomson Any updates on Adding |
Beta Was this translation helpful? Give feedback.
-
|
the latest thread found on the same #12764 |
Beta Was this translation helpful? Give feedback.
-
|
Bump |
Beta Was this translation helpful? Give feedback.
-
|
Bump |
Beta Was this translation helpful? Give feedback.
-
|
I think you could technically use |
Beta Was this translation helpful? Give feedback.
-
|
bump |
Beta Was this translation helpful? Give feedback.
-
|
bump |
Beta Was this translation helpful? Give feedback.
-
|
bump |
Beta Was this translation helpful? Give feedback.
-
|
bump |
Beta Was this translation helpful? Give feedback.
-
|
This arguably shouldn't actually be a new "type", but simply an attribute of each input value: inputs:
foo:
type: string
a-secret:
type: string
secret: true |
Beta Was this translation helpful? Give feedback.
-
|
I was struggling with the same problem, but read a blog that solved this using jq to retrieve the input value from $GITHUB_EVENT_PATH and then adding an echo mask. I tested this and actually expected to find the input value somewhere in the workflow run logs - at least when re-running with debug logging - but I was not able to find the secret value anywhere in the logs! Could this be used as a workaround, or is there any problems I haven't seen? 😄 Edit: An example workflow file: name: Example workflow with secret input
on:
workflow_dispatch:
inputs:
password:
description: 'A secret value none should be able to read'
required: true
type: string
jobs:
example-job:
runs-on: ubuntu-latest
steps:
- name: Create secret environment variable
run: |
SECRET_PASSWORD=$(jq -r '.inputs.password' $GITHUB_EVENT_PATH)
echo "::add-mask::$SECRET_PASSWORD"
# SECRET_PASSWORD can now be used without being logged |
Beta Was this translation helpful? Give feedback.
-
|
Please make this natively supported. This is a very basic feature for CI to have |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
There are times in operations pipelines when you have to pass in a secret through the workflow input. However, currently there is no way to input a masked secret like a password field. Also, even using echo mask the first step that runs you can expand and see the secret in the output of the job.
There needs to be an input type secret that masked it like a password input field and in the debug output of the pipeline run.
Is this something that is already planned? I feel like this is a major lacking feature to really be able to utilize github actions in a true operational function. Most CI platforms give you this option but github actions doesn't. Then the echo mask doesn't maxed the expandable debug output in the first step that is run in the pipeline. Meaning even if you are ok with passing it in at execution time not masked it is exposed in the job run. One way I'm getting around this is deleting the job run after its done with a remote execution cleanup job.
Obviously super jenky and still risky even for a private repo and self hosted runners. This would improve the platform quite a bit.
Other input types, and allow more than 10 inputs.
Thanks for reading.
Beta Was this translation helpful? Give feedback.
All reactions