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:
git-lfs/git-lfs#2133

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

@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.

Hi @mneudert

Do you maybe have an update on the progress of migrating to the latest Travis architecture in Core and plugins? Thanks!

I have to admit I sort of forgot this issue :D

Working on it right now with some pull requests incoming soon!

After the merge of #12405 this should be finally completed. After all there is no longer any build running on the old precise infrastructure 🎉