Comment on Github Pull Requests

[coveralls-net]

Comment on Github Pull Requests

[jdeering]

This has been added. Be aware that, when using AppVeyor, pull requests do not decrypt secure environment variables. If COVERALLS_REPO_TOKEN is set as a configured environment variable (either in yml or in UI) and it's encrypted, calls to coveralls won't work.

[giggio]

Right... How to solve this? Any idea?

[jdeering]

• Don't use yml for configuration and stick strictly to AppVeyor's UI for setting up your builds. Set the environment variable with your token unencrypted.
• Ask AppVeyor to change how this works.
• Use a different CI service.

I'm planning to personally research other available CI options for my own personal use as well as to provide support for this project across more platforms.

[FeodorFitsner]

I've checked coveralls.net utility and I think it would be pretty easy to add "native" support for it into AppVeyor. We could have like a new coveralls section in appveyor.yml. This way it will work in both regular and PR builds (adding another deployment provider won't work as deployment is also disabled for PR builds).

[jdeering]

Works for me. Let me know if there's anything I can do to help with this.

[FeodorFitsner]

Cool, thanks!

[giggio]

@FeodorFitsner That would be awesome!

[gep13]

So, having just recently set up Coveralls for a small project that I am working on, I was curious about this ability to comment on GitHub. Are we saying that I can't use an environment variable to do this work? If so, can I use settings both from the UI and from my YAML? What is the state of this from an AppVeyor point of view @FeodorFitsner ?

Thanks!

[FeodorFitsner]

So, we agreed on adding built-in support for coveralls, but I can't give you an ETA yet.
Yes, you can define vars on both UI and in YAML.

[gep13]

So, in theory, assuming that I add the Coveralls token to the AppVeyor UI, I should currently get commenting on Pull Requests when using this application to publish to coveralls. Is that right? /cc @jdeering

[FeodorFitsner]

Yes, unless it's unencrypted it will be merged into vars defined in yml and available in PR build. But again, anyone with bad intentions could steal it by submitting PR listing all environment variables.

[gep13]

@FeodorFitsner said...
anyone with bad intentions could steal it by submitting PR listing all environment variables.

Yip, valid point. :+1+ Right now, it is not an essential addition for me, only just got Coveralls and Coverity set up on my small project, and was curious when I saw this feature within Coveralls.

[TerribleDev]

👍 on this as well

[clairernovotny]

@FeodorFitsner any updates on this -- on figuring out a secure way to make this work for PR's?

[FeodorFitsner]

Actually, there is a new option Enable secure variables in Pull Requests from the same repository only (on General tab of AppVeyor project settings) that is available for both public and private projects and may work for this case.

[clairernovotny]

@FeodorFitsner is that something I need to configure in the AppVeyor.yml or only in the UI?

[FeodorFitsner]

It's UI only.

[clairernovotny]

@FeodorFitsner The UI option works great for PR's from branches that are in the same repo, as designed, but it still leaves a gap for PR's from external contributors.

I suspect that the only secure way to do it would be or AppVeyor to provide its own coveralls.net binary and invoke it as part of a separate dedicated step and pass the repo-token parameter directly. That'd prevent exposure to scripts/items in the PR itself.

Any chance of that happening?

[jdeering]

This issue is primarily related to functionality in AppVeyor itself and not related to the coveralls.net tools as they are currently implemented.