Closed uhaciogullari closed 9 years ago
Can you point out where this issue is occurring? This is handled, by passing the environment variable name to the app when you run it.
I'm not familiar with appveyor configuration but there is also a value here:
https://github.com/csMACnz/Coveralls.net-Samples/blob/nunit-opencover-appveyor/appveyor.yml#L12
Ah, so that is indeed a secure appveyor environment variable. you need to use their secret key to decrypt it. which only happens on their build agents during a branch build.
The reference for how this works can be found here: http://www.appveyor.com/docs/build-configuration#secure-variables
Thanks for your comments.
Missed that one, thanks. AppVeyor also lets you set them from project settings, it's a nice alternative I think.
I started using that approach. I find that the flexibility of an appveyor.yml file allows me to vary configs between branches. I didn't realise you could have the environment variables on the server, and still have the rest of the config in the appveyor.yml file. Personally, I prefer the config file in my repository over the hidden config inside the build server, and keeping all the settings in one place.
Also, at least for the demo purposes of this samples repo, It allows others to see how my appveyor build runs coveralls (config and all) so they can get it working on their repo. However I might add comments to indicate that you can leave the Environment Variable on the server as well.
Also note, as a security feature, Pull Requests do not have access to secure environement variables (set on the server or in the appveyor.yml file) So there is no way of it being stolen by being in the public. It is also easy enough to reset on coveralls.io as well.
Thanks.
Thanks for the sample. I would like to point out something. Repo tokens should not be exposed in build configuration. AppVeyor lets you create environment variables in project settings.