@mattab opened this Issue on August 30th 2017 Owner

-> Goal of this issue is to use the latest Travis CI infrastructure documented here

Current status

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

First error on new distribution

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

from here: https://travis-ci.org/piwik/piwik/jobs/269029296


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.

@mattab commented on August 30th 2017 Owner

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?

@sgiehl commented on August 30th 2017 Member

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 sudo:false

@mneudert would you maybe be keen to do that?

@mneudert commented on August 30th 2017 Member

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?

@sgiehl commented on August 30th 2017 Member

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.

Powered by GitHub Issue Mirror