Environment variables not loading on travis for external PRs

[kaustubh-nair]

Travis does not load environment variables due to security concerns, (https://docs.travis-ci.com/user/pull-requests#pull-requests-and-security-restrictions)
This is a valid security concern because anyone can send a PR that prints and exposes the env variables to the logs.
It is however a setback for us since it restrains us from sending coverage reports to Coveralls/Codeclimate. Because of this we can't see coverage change on external prs. (This is important for us because we might want to encourage contributors to send prs with sufficient tests so that test coverage does not decrease)
For example compare #467 and #462

The same issue exists for plots2 as well. Notice how a repo can't be found to send report to coveralls in this build. https://travis-ci.org/publiclab/plots2/builds/512970864#L3498
Currently only push builds are sending coverage reports to coveralls.

I can't find a good solution for this that doesn't include making the environment variables public, which should be our last resort.

[kaustubh-nair]

Someone please add the discussion label 😅

[jywarren]

Done, also adding you as a collaborator you you can too! 👍

[kaustubh-nair]

@icarito do you have any ideas about this?
Thanks

[alaxalves]

@kaustubh-nair If if have understood well the problem here I think that we could use Travis CLI to encrypt any kind of file we want(In our case a .env file) and then decrypt the file in travis.yml, export those needed variables and use them inside our build. Maybe something like I have set here:
https://raw.githubusercontent.com/falko-org/Falko-API/1f2bd28964a82ede6c9ea56084fab29589ffe8d3/.travis.yml

Note that in before_install: job I decrypt a previously encrypted private key in ~/.travis/alax-digitalocean-key.enc path. After that I use this key to auto deploy in a DO vps.

[kaustubh-nair]

@alaxalves Travis documentation says encrypted files are not available for pull requests across forks https://docs.travis-ci.com/user/encrypting-files/
So your solution doesn't solve our problem

[kaustubh-nair]

@jywarren @alaxalves I guess whatever solution we implement, the env variables will always be available be during the build, thus open to being accessed. So I don't really think there is any point in encrypting these. What do you think? Should we put the coveralls token in travis.yml?

[jywarren]

Hmm, we can just as easily put them in the Travis settings env. variables, unencrypted, right? Thank you!

…

On Tue, Apr 9, 2019 at 2:05 PM Kaustubh Nair ***@***.***> wrote: @jywarren <https://github.com/jywarren> @alaxalves <https://github.com/alaxalves> I guess whatever solution we implement, the env variables will always be available be during the build, thus open to being accessed. So I don't really think there is any point in encrypting these. What do you think? Should we put the coveralls token in travis.yml? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#491 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ7JGAAdaJv3YOyo3_4glzPtb7Wzjks5vfNZPgaJpZM4cfLDP> .

[kaustubh-nair]

@jywarren No we can't do that. It's mentioned here that Travis does not load env variables from settings for external PRs. That's why coveralls is working for internal but not for external PRs

[alaxalves]

@kaustubh-nair Isn't there a space in Mapknitter's project settings where we could set env variables, just like we have in Gitlab?

[kaustubh-nair]

@alaxalves Hmm, I don't think Github has that feature. If I am right, only gitlab has that.

[jywarren]

Hi all, sorry i hadn't had time to chime in here. Just to clarify, what makes a PR internal or external? #467 and #462 are both by project collaborators, no?

In any case, I'm OK with putting them in travis.yml, and we can see how that works. We can always revoke and revert. What should the format be? I can add to a PR with a travis.yml update...

[kaustubh-nair]

Internal PRs are created from a Mapknitter branch and external ones are sent from a branch across a fork.
If you think it's okay to make the token public, I'll send a pr!
Cheers

[jywarren]

Yes let's do it!!! Thanks!!!

…

On Sat, Apr 13, 2019, 10:07 PM Kaustubh Nair ***@***.***> wrote: Internal PRs are created from a Mapknitter branch and external ones are sent from a branch across a fork. If you think it's okay to make the token public, I'll send a pr! Cheers — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#491 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJxZaTqqDbEtI_J7Nb175N_jp5NXZks5vgptUgaJpZM4cfLDP> .

[sashadev-sky]

@jywarren @alaxalves was this resolved with the switch to codecov(#543)? can it be closed?

[alaxalves]

@jywarren @alaxalves was this resolved with the switch to codecov(#543)? can it be closed?

I think that f88fa70 already solved this but I might be mislead, @kaustubh-nair Can you answer this?

[kaustubh-nair]

This isn't really resolved, the point of this issue was that it was a prerequisite to getting Coveralls working.
But since we've got Codecov set up, this issue is not important anymore
So we can close this.

[kaustubh-nair]

Or we can keep it open, in case it is required for something else in the future?

[sashadev-sky]

@kaustubh-nair @alaxalves if it was specific to coveralls lets just close it. It's likely in the future it'd just be easier to start clean and the information in the issue is still available when its closed. Im all for less clutter