This is something I’ve wanted for a while but seems even more useful now due to the Docker Hub pull limit changes (see this post, I’m mainly referring to the linked GitHub issue).

Many people input their Docker repository username as a secret. This can be useful as you can:

1. Change them without committing a change (especially useful if it’s more urgent and you have a PR policy)
2. Censor it if it’s an email or another random account (e.g. a designated CI account/token)

But, when you’re doing something like maintaining a library, you are often using Docker Hub and the same username to push (and even pull in the future) as the Docker Hub repository owner. Using a secret results in unnecessary censoring which could make logs quite difficult to read. If you end up switching to a designated account or use something like Google Container Registry, you would want to switch to a secret as the username may be sensitive, but the only way to do both of these things is to initially have it hard coded into the workflow (e.g. an env var) then commit a change switching it to a secret. Initially using a hard coded value loses the first advantage mentioned above.

I was initially thinking of a separate settings-like tab where you could enter variables (which wouldn’t simply be passed into every workflow and step and instead behave similarly to secrets), but having a toggle in the add secret input would make more sense, be less confusing, make it more visible and have it be very similar to an existing setup (no referencing non-censored variables as a secret in the workflow).

Having a tick box when adding/editing a secret which marks it as non-sensitive (meaning it is not censored in logs) along with some indication in the secrets list that it is not censored (and maybe even showing the existing value when editing it/allowing users to see the value of it without resetting it) would help make logs more readable in some cases and allow for the benefits of secrets to be used for more things. There are probably more examples than Docker usernames which would also benefit from this feature.