openscreenprotocol icon indicating copy to clipboard operation
openscreenprotocol copied to clipboard

travis-ci jobs to commit index.html changes are failing

Open markafoltz opened this issue 4 years ago • 6 comments

It looks like since October, the travis-ci jobs to update our generated spec (on the gh-pages branch) when pull requests are merged is failing.

Example today: https://travis-ci.com/github/w3c/openscreenprotocol/builds/218631036

What is failing is the step in deploy.sh to extract the encryption keys from Travis environment variables.

+ENCRYPTED_KEY_VAR=encrypted_6c9ad971e3e1_key
+ENCRYPTED_IV_VAR=encrypted_6c9ad971e3e1_iv
+ENCRYPTED_KEY=
+ENCRYPTED_IV=
+openssl aes-256-cbc -K -iv -in ../scripts/deploy_key.enc -out ../scripts/deploy_key -d
iv undefined

It's been too long since I set this up to remember how to fix it. Maybe @tidoust is familiar with how other repos are doing this and can point to a working script?

markafoltz avatar Mar 01 '21 21:03 markafoltz

It looks like Travis isn't setting the environment variables with the encryption key/IV for the GitHub key that the script needs to push commits to the repo.

@tidoust, it looks like you set this up originally in PR #230. Do you mind seeing if you can re-generate these keys with Travis, or send me instructions on how to do so?

markafoltz avatar Mar 01 '21 21:03 markafoltz

TLDR: I enabled a temporary workaround but I need to re-generate the keys and deploy_key.enc for a proper fix.

A longer explanation: That is because there are two travis-ci domains in practice for the same service, which is something I realized only recently. There is the old travis-ci.org which was triggered through a Webhook, and the new travis.com, which is enabled at the W3C organization level on GitHub, and does not require any Webhook.

When the repo transitioned from Webscreens to W3C, the environment variables attached to the travis-ci.org repo configuration should have been automatically migrated to travis-ci.com (at least according to the documentation). For some reason, that did not happen. I may have pushed the wrong button at the time (I don't recall having pushed any Travis-CI button...).

The Webhook remained in place for some time, and two Travis CI jobs were run in parallel each time a push was made: one handled by travis-ci.org, which succeeded, and one handled by travis-ci.com, which failed because the environment variables had not been copied over.

Then, circa October 2020, I probably noticed the webhook and dropped it, because, in theory, it is completely useless. That successfully resolved the duplication of Travis CI jobs, but also meant that the travis-ci.com one is the only one that now runs, and that job can only fail since it does not have the right encryption keys to push to the gh-pages branch.

I temporarily re-enabled the webhook to travis-ci.org, and forced a new build of the spec: https://github.com/w3c/openscreenprotocol/commit/776ccc8f359492f551fd6a1583433e2477ba2c6a

While the webhook is in place, we will likely see two Travis CI jobs again on each push (with one that fails).

I'll re-generate the encryption key and set env variables on travis-ci.com, and will drop the webhook for good afterwards.

tidoust avatar Mar 02 '21 10:03 tidoust

Interesting! I had no idea that we had two sets of Travis jobs running. Thank you for keeping the old one limping along, and hopefully the migration to travis-ci.com will be straightforward.

markafoltz avatar Mar 02 '21 19:03 markafoltz

@tidoust It looks like both the Travis-CI and the GitHub workflows jobs are running after pull requests are merged. It also looks like they are running bikeshed in slightly different ways, so one commit is undoing the changes landed by the other. For example Travis-CI is adding <p> tags to the messages appendix and GithHub is removing them.

Maybe it's time to remove the hook running the Travis-CI job?

markafoltz avatar Mar 03 '21 19:03 markafoltz

Hmm. Removing the .travis.yml file should have been enough to stop Travis CI. I suspect that Travis CI thought it had to run because the .travis.yml file still exists in the PRs you merged and that is what Travis CI uses as basis. This seems broken to me but there must be some logic behind that...

Rebasing the remaining PRs against the master should prevent that from happening. I dropped the Webhook and I tried to turn everything off on travis-ci.org and travis-ci.com (but I'm not clear that there is a proper "shutdown" button there).

tidoust avatar Mar 03 '21 19:03 tidoust

Ah, that could explain it. I'll rebase any outstanding PRs before attempting to merge them.

markafoltz avatar Mar 03 '21 22:03 markafoltz

I've been able to land multiple PRs and the HTML spec generation seems to be working with GitHub workflows.

markafoltz avatar Sep 09 '22 23:09 markafoltz