Travis-CI Windows Job Hang

[garyyu]

There's a known bug in Travis-CI: https://travis-ci.community/t/current-known-issues-please-read-this-before-posting-a-new-topic/264/10

a Travis CI encrypted environment variable in .travis.yml OR an environment variable in the Travis CI UI that doesn’t have “Display value in build log” checked, will cause a Windows job to hang.

Because we have a GITHUB_TOKEN environment variable (definitely can't let it display in the log), we can't enable the windows Travis-CI at this moment.

To see how this hang look like: https://travis-ci.org/garyyu/grin/jobs/504540031

Better to wait till Travis-CI fix this issue.

[garyyu]

Related pending task: https://github.com/mimblewimble/grin-pm/blob/master/notes/20190305-meeting-development.md#5-enabling-nightly-builds-and-test-runs-for-windows--macos

I will try to enable the daily build for macos firstly.

[yeastplume]

To get around this issue to create windows builds, I just remove the API key temporarily, comment out everything but the windows build call, and let it build. Very annoying but there's no indication as to when this Travis CI bug issue will be addressed. I suspect it's because their libs for decrypting keys are linux only and won't run on the windows env.

It's kind of important though that we ensure we support windows properly, especially given the number of people looking forward to it and/or excited about it. I haven't investigated, but do you know offhand if it's possible to have a repository monitor for upstream changes, then automatically merge/build and test? I'm thinking it might be better to keep a separate grin-win-build repository for this if we could do something like that.

[hsk81]

@yeastplume In one of my projects (https://github.com/percim/api-explorer/releases) I had the same issue. What I did was to:

• fork the original repository (from https://github.com/hsk81/api-explorer),
• create a new percim-bot account (GitHub policy explicitly allows such accounts),
• make the percim-bot account a collaborator for the forked repository,
• give the bot account a public_repository scope access,
• create credentials for that bot account (using Travis' CLI),
• and provide those to Travis CI in plain text.

Now, my percim-bot account is able to publish Windows releases (to the forked repository). It's a little convoluted, but it still allows me to

• protect the original repository,
• have only the percim-bot account's (release) credential leaked,
• but which has only public_repository access to my forked account.

In theory this is still sub-optimal because now anybody could fetch the release key of the bot account (from the Travis CI logs) and fiddle around with the releases, but at least my original source base is protected from malicious access. And I can still revoke / refresh the release key for the release bot.

[garyyu]

but do you know offhand if it's possible to have a repository monitor for upstream changes, then automatically merge/build and test?

can be done in Travis-CI, but must leak the GITHUB_TOKEN environment variable and then the repo is NOT safe (it's open to anyone who know this token).

I'm thinking it might be better to keep a separate grin-win-build repository for this if we could do something like that.

Considering the complexity of manually merging, keeping a separate grin-win-build repository could not help much.

[0xmichalis]

This issue can be closed now.