travis: Remove travis

MarcoFalke commented at 2:11 pm on June 18, 2019: member

Travis stopped working for no apparent reason and no way to fix, so remove it. Tests are still run on appveyor and developers can run tests locally with make check && ./test/functional/test_runner.py.

Fixes #16148 (Travis timeouts)

travis: Remove travis 97f8eb8425

fanquake added the label Tests on Jun 18, 2019

fanquake added the label Needs Conceptual Review on Jun 18, 2019

laanwj commented at 2:19 pm on June 18, 2019: member

Drastic.

I’d prefer to have a replacement for Travis first, and not rely on Appveyor only. The drawback of local testing is that it only covers one platform, generally.

On the other hand, if Travis has become useless then this makes sense, I’m sure false positives consume a lot of developer time.

practicalswift commented at 2:21 pm on June 18, 2019: contributor

Concept NACK

Doing this as suggested is a very risky move: we will lose automated testing under ASan, TSan, UBSan and Clang thread-safety analyser.

This should not be rushed.

practicalswift commented at 2:43 pm on June 18, 2019: contributor

Until we have a proper Travis replacement in place: why don’t we just pay Travis to get this resolved?

Paid working Travis must be strictly better than this rushed “no Travis” alternative, no?

fanquake commented at 2:46 pm on June 18, 2019: member

why don’t we just pay Travis to get this resolved?

We already pay Travis as far as I’m aware.

practicalswift commented at 2:50 pm on June 18, 2019: contributor

We already pay Travis as far as I’m aware.

No we don’t :-)

See #16148 (comment).

laanwj commented at 2:54 pm on June 18, 2019: member

I don’t think it’s as easy as “simply pay travis”. There might be other CI hosters more open to paid service for open source projects, but for Travis this has always been difficult (and this has been discussed for literally years).

MarcoFalke commented at 2:58 pm on June 18, 2019: member

We used to pay them, but they nudged us about a renewal. And in light of it being useless, I don’t see why we should purchase parallel jobs again.

Hi Marco,

My name is Sara and I am your new Renewals Representative for Travis-CI. Our record indicates that your subscription for 15 build plan expired on April 4, 2019

If this is an over-sight, please let me know and I will send you a quote to reactive your subscription. Or if you have decide to not renew your subscription, I would appreciate if you could give me a short feedback on your experience with Travis-CI and the features you would like to see in Travis-CI in future.

I look forward to hearing from you soon.

Thank you and have a great day.

practicalswift commented at 3:04 pm on June 18, 2019: contributor

We used to pay them, but they nudged us about a renewal. And in light of it being useless, I don’t see why we should purchase parallel jobs again.

I would like to pay until we have a proper Travis replacement in place. I find it very important that we don’t lose automated sanitiser testing for all new code entering the repo.

Where shall I send money and how much? Perhaps it would be easiest to pay it one year in advance to minimise administrative overhead. Feel free to mail me the details.

MarcoFalke commented at 3:14 pm on June 18, 2019: member

@practicalswift Travis is not running because the caching is not working. Throwing money at them won’t magically fix that.

I have a ticket with them Travis CI: [8383] - Caching issues on travis infrastructure. You are welcome to contact support as well or try to fix the caching issue in some way. Though, if we can’t fix it there is no point in either keeping travis or paying them.

We absolutely need a working cache to build depends and then build Bitcoin Core based on those depends to mimick our release binaries that are also built with depends. Without a cache, compile times are not manageable.

MarcoFalke commented at 3:20 pm on June 18, 2019: member

I am going to purge all caches again and re-run some builds, but honestly I am not expecting anything to change.

jonasschnelli commented at 3:41 pm on June 18, 2019: contributor

Instead of completely removing, would it make sense to reduce Travis to only build against system libraries (remove the depends builds)? Then eventually add the dependency builds through semaphore2 with the restriction of missing public view access to the build log for now.

MarcoFalke commented at 5:35 pm on June 18, 2019: member

@jonasschnelli Yeah, that would be an option, but then we’d maintain three ci solutions. Not sure if that scales well.

MarcoFalke commented at 5:36 pm on June 18, 2019: member

Deleting all caches and rerunning some builds didn’t fix anything. Also, the travis output of the cacher is completely useless:

https://travis-ci.org/bitcoin/bitcoin/jobs/545179929#L152

jonasschnelli commented at 6:00 pm on June 18, 2019: contributor

@MarcoFalke maintaining one additional CI during a time of transition (or uncertainty) is probably okay.

Would implementing our own cacher be an option (tar, upload to a custom filespace)?

DrahtBot commented at 6:45 pm on June 18, 2019: member

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#16161 (util: Fix compilation errors in support/lockedpool.cpp by jkczyz)
#15993 (net: Drop support of the insecure miniUPnPc versions by hebasto)
#15584 (build: disable BIP70 support by default by fanquake)
#15134 (tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) by practicalswift)
#15112 (build: Optionally enable -Wzero-as-null-pointer-constant by Empact)
#14920 (Build: enable -Wdocumentation via isystem by Empact)
#14505 (test: Add linter to make sure single parameter constructors are marked explicit by practicalswift)
#13728 (lint: Run the CI lint stage on mac by Empact)
#12134 (Build previous releases and run functional tests by Sjors)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

luke-jr commented at 10:18 pm on June 18, 2019: member

I also tried to solve caching with Travis before our paid service expired, and their support staff were useless.

No reason to keep Travis enabled when it isn’t doing anything useful. Sure, it’d be great to have *San tests running automatically, but right now they don’t seem to be.

practicalswift commented at 1:53 pm on June 19, 2019: contributor

Is it just me… or is Travis feeling faster than ever before since today/yesterday? :-)

MarcoFalke commented at 3:12 pm on June 19, 2019: member

Ok, closing until we found a replacement.

MarcoFalke closed this on Jun 19, 2019

MarcoFalke deleted the branch on Jun 19, 2019

practicalswift commented at 3:19 pm on June 19, 2019: contributor

@MarcoFalke Can you describe what happened yesterday?

Did we start paying? Did Travis put the correct engineer on the case? Or both? :-)

I’m trying to understand why it is suddenly super quick and if the current swiftness can be assumed to be permanent or not.

MarcoFalke commented at 3:21 pm on June 19, 2019: member

@practicalswift Nothing sped up. It is back to normal.

See the reply here: #16148 (comment)

practicalswift commented at 3:25 pm on June 19, 2019: contributor

@MarcoFalke Ah, so Travis pushed a fix and everything else remained constant. Does Travis work as we want it to now? In other words: should we see the “Travis situation” as resolved?

I take it we are not paying?

MarcoFalke commented at 3:48 pm on June 19, 2019: member

I asked them for a quote for the next year, but they haven’t replied yet.

DrahtBot locked this on Dec 16, 2021

travis: Remove travis #16232

Conflicts