bitcoin: Travis timeouts

I don’t but if it would be helpful to the project I can try to establish a connection. If I get a few thumbs up on this comment I’ll prioritize it. I’d want to know what the project’s history is with Travis.

Hi Marco, thank you for your follow up and your patience here. We pushed a fix that should hopefully resolve this. If you haven’t had a chance to restart your builds, could you try doing so? Once again thank you for your patience as well as your collaboration here. Please don’t hesitate to follow up if you’re still observing issues.

I haven’t prioritized it due to only 2 thumbs up and Marco suggesting we spend our resources in a different way. If more contributors including at least one maintainer voice support for me engaging Travis, I will be happy to do so.

Added a thumbs up, I would encourage others to do the same. We need to transition from Travis but during that transition period we need to get by as best we can.

Would the Travis timeouts be less frequent if we paid them more?

I did get a reply from travis with ideas to explore:

---

Hey Marco,

Thank you for your reply and for sending us these links to newer instance of the issue.

I have some suggestions for you to try. Ideally you should try them independently.

1. Clear the content of the daemon.json config with a snippet similar to the following:

before_install:
  - echo '{"registry-mirrors":["https://mirror.gcr.io"]}' | sudo tee /etc/docker/daemon.json
  - sudo service docker restart

Right now this file contains the following: {“registry-mirrors”: [“https://mirror.gcr.io”], “mtu”: 1460} and I’m wondering if the mtu setting could be at play.

1. Change the archive.ubuntu.com URL with the following command:

sed -i -e 's/http:\/\/archive\.ubuntu\.com/http\:\/\/us-central1\.gce\.archive\.ubuntu\.com/' /etc/apt/sources.list

Please ensure to call this command before calling apt-get update.

I hope this helps and please let us know the results you will get.

---

GitHub Actions is lacking support for caching last time I looked, so the build take longer than on travis. I’d prefer to wait until caching is supported.

Semaphore just made us a nice offer, basically 16 parallel jobs of 2 vCPU 3.4GHZ 4GB Ram machines for free.

Since travis is back running… I don’t know what to do.

Travis just confirmed to me it was an issue on their side:

Hi Marco, thank you for following up and glad to hear you were able to resolve this on your end. I apologize for the inconvenience. I can confirm that relative paths were broken but should now be fixed. Considering your builds now work with absolute paths, I just wanted to let you know that if you feel inclined to try with relative paths again, I’d be curious to see if you observe any issues. Thank you for your patience again and wishing you a great weekend.

@MarcoFalke how difficult would it be to “Run a helper script to poll travis failures and rerun them if the failure was due to a timeout” or “Rerun about-to-time-out jobs from within travis” as suggested in the issue description? I understand doing these things wouldn’t solve every problem, but it seems like they would solve most of the current problems with no downsides and not be too difficult to implement. The second option “Rerun about-to-time-out jobs from within travis” seems especially appealing and it looks like there’s an existing implementation of it with curl here: https://github.com/plume-lib/trigger-travis#use-in-travisyml

The only potential downside I see is that logs from “Error! Initial build successful, but not enough time remains…” builds would be discarded, but since successful build logs probably aren’t very interesting, this doesn’t seem so important.

I guess in the longer term, it does seem like we are pushing against travis limits and might need to find other solutions.

Supports all of those listed points.

1. Free package (for open-source projects with 4x parallelization), forks are also supported by default
2. Haven’t tested it too much but there’s definitely a permission system for contributors/members of orgs
3. Yep should be possible and afaik there are no limitations for either caching, matrices limitations

To put in a nutshell, I wouldn’t see any blocker that would keep you away from doing the same things that are being done on TravisCI. And there even more pretty neat feature to support easy maintenance for all those tests. But to stay realistic, the only downside I could see is that you have everything inside a yaml file which is (in my opinion) not that easily readable and become quite huge after some time : ^(