yep, same issue
Both our builds have the same config but some of them ignore the repo key and switch back to the default repo key. This started last friday, was there a recent change to the travis config api? Seems like a bug. Why is my ssh key being ignored when its on the settings tab of a specific build?
Installing SSH key from: default repository key
Installing SSH key from: repository settings
We are also facing the same issue.
As a workaround, I have tried adding the encrypted key to .travis.yml, but the build is not able detect the environment variables. It happens only for the pull requests.
openssl aes-256-cbc -K $encrypted_xxxxx_key -iv $encrypted_xxxxx_iv
-in travis_deploy_key.enc -out ~/.ssh/id_rsa -d
Appreciate any help
@laszlof Please let me know once you get some response on the ticket.
That lines up with when ours started doing the exact same thing. Same thing from build logs as well. Even though a key is defined in repo settings, its using the “default repository key” instead. Confirmed via debug build and comparing.
cycling your secrets is something that all users should do on a regular basis. If you are unsure how to do this please contact Support.
We cycled our keys as recommended by the security bulletin but that does not work either. It seems like ssh key variables are plain broken at the moment.
Sadly, all of our repo’s are private, and should not be affected by this.
I am also facing the same issue and our repo’s are private as well.
Same problem since 2 days, the support is silent. It’s awful.
(paid travis-ci.com user) We have a Github private repo in our Org that includes a submodule from a public repo, also from our Org. PR and deployment builds are failing, either at the submodule init or at the hosted Dev/Stage environment for develop-build or master-build. This has halted the code deployment schedule for a major CMS version upgrade of a large website. Also has wasted many hours of dev and devops time to diagnose. We have replaced deployment keys but that has not solved the problem. If Travis can’t solve the problem this week, we will have to find and implement a new CI solution in order to meet deployment schedule.
After 2 days we haven’t got a reply from support yet. Some of our repos work fine and some others don’t.
If anyone gets a response from support, please write it here so at least we maximise our understanding of the issue, thanks!
A temporary workaround we found is to, instead of creating a PR from a fork, pushing the branch to the upstream and then creating the PR from within the same repo (the original).
This seems to allow the proper injection of the key.
FYI. I just got a reply back from support. Here is the contents:
Thank you for contacting Travis-CI Support. I am sorry to hear that you are experiencing issues with Travis-CI. We introduced an enhancement earlier this week that removed the ability to use the base repository SSH key in pull requests from forked repositories. If you want to make a pull request from the fork to the base repository you will need to add the base repository SSH key to the fork before creating a pull request and running builds.
Once again, I am sorry for the inconvenience this may have caused. Please let me know if you have any questions!
But Github deploy keys can only be added to one repo. We tried adding the same key to forked repos but then Github does not let you reuse the key. Then, we tried creating a new key but travis only lets you have one ssh key.
Finally, we try the machine user approach. That did not work either.
How was this rolled out without testing it? The irony of CI.
Same here. The CI machine user approach described in Private Dependencies GitHub - Travis CI is already what we are using.
On our side this is very strange because it seems to be affecting only certain repos which worked flawlessly up to last week. I have gone back to support for further advice.
As suggested by Travis CI build not loading correct SSH key - #14 by lzambarda, push branches directly on upstream instead origin (fork) is ok for now but resolve the issue will be welcome!
For Github users: we have implemented a different approach that is now working.
We have a Github Org, with an account that is only used to manage the Org (a “machine user”). We have given the Travis SSH key.pub to that user (Settings: SSH/GPG keys), and removed the key.pub from the Deploy Key on the repository. As long as the key holder user is in a Github Org Team that has permissions on the repo, the key will be found by Travis as the repository key and all users in the team can have successful PR builds from their forked repo to the base/upstream repo.
Machine user approach did work… but NOT immediately. It just magically began working today after we implemented it yesterday.
Just got a reply from the support:
This change has been rolled back for private repositories.
I received a reply from support too:
It should be working as it was working before.
And I can confirm that the machine is now printing:
Installing SSH key from: repository settings
As it did before.