Anyone, even PRs can have secrets

We've received several requests to make our secret env vars visible for pull requests, but initially we decided not to let them appear on PRs because it could cause security issues. For example, if you are developing an open source project in which these envs would get public during a PR, with the changes others could manage to get your secrets. However, for most use-cases this scenario does not make sense, so we now allow you to opt-out from this to expose your secrets if you wish.

The default setting for new and old secrets is withholding the secret envs, but from now on you can change this, yay! Now you and your teammates can work on the same projects more easily, but outsiders still won't be able to access your data as the logs are not public anyway. (This might even come handy if you plan to develop tools based on Bitrise CLI.)

So, how do we do that?

A new meta field (meta) was added to EnvironmentItemOptionsModel. This property of the environment options is used to define extra options without creating a new envman release. Meta is a universal property that was designed for other tools to define properties and keep these in the Bitrise config. It provides new possibilities for secret envs.

The bitrise-cli does not use this meta field directly, but other tools can use this property to expand the environment options. For example, the bitrise.io website will use the meta field to define if secret environment variables should be used in pull request triggered builds or not.

You can change the secrecy settings in two places in the Workflow Editor:

1, generally

2, for each file

And this is what the YML should look like:

.bitrise.secrets.yml

envs:
- MY_SECRET_ENV: secret value
  opts:
    meta:
      is_expose: true

Happy coding! 🚀