-> Goal of this issue is to use the latest Travis CI infrastructure documented here
Recently our builds were running on the latest Travis CI infrastructure and they were failing with the message below. For now we reverted to use the older infrastructure in https://github.com/piwik/piwik/commit/485f61ecacec0346637708e2b1483ef1067167b6 and https://github.com/piwik/piwik/commit/6846058d80df8e5c158541c3e6471567df77ac69
Error downloading object: tests/UI/expected-screenshots/Login_password_reset.png (8c6d242): Smudge error: Error downloading tests/UI/expected-screenshots/Login_password_reset.png (8c6d242ab1e0cd44333e359adf6f3b6c49123a41b0cf3712e7afa2ea6121bca6): batch response: Rate limit exceeded: https://github.com/piwik/piwik.git/info/lfs/objects/batch
As travis explains it seems that we will need to upgrade in the next few weeks:
By the end of September 2017, we hope to have 100% of incoming configurations with dist: precise routed to the sudo-enabled infrastructure, and to retire the container-based infrastructure. We have no immediate plans to discontinue support for jobs that specify sudo: required and dist: precise, although we do not plan to update the images for these jobs any more.
contacted Github support about the error and they replied:
We have API Rate limits set up for the download of LFS files. I would guess that the clone request is being made as an Unauthenticated request, rather than an Authenticated one. You should be able to change this to use Authentication which would increase those limits. The post below has some guidance on how to set this up:
So maybe we try the solution in the git-lfs issue?
I think this will be a "bigger" project. The new infrastructure has way more changes to be done.
Skipping the LFS smudge in the beginning wouldn't be a problem, but it then fails afterwards when trying to configure git with username and email and if skipping this the setup of the webserver fails...
Actually I believe it might be most useful to build the new travis setup from scratch and maybe (if possible) with
@mneudert would you maybe be keen to do that?
Switching over to a partially sudoless infrastructure sounds like something I would really like to try.
Partially only because I think the ramdisk used in some tests only works that way. But afaik it is possible to activate sudo on a per-job base without the global requirement.
But that might still not solve the problem with the git credentials. Wouldn't it work using some travis secure token to at least get everything up and running until a complete switch can be made?
Yes. Secure token should work as well. For now the builds are running on old
precise infrastructure and that should work until we switch to the new one.