Migrate the Travis configuration to travis-ci.com

[style95]

Description

Fix #5041

Related issue and scope

• I opened an issue to propose and discuss this change (Update the travis configuration to apply travis-ci.com #5041)

My changes affect the following components

• API
• Controller
• Message Bus (e.g., Kafka)
• Loadbalancer
• Invoker
• Intrinsic actions (e.g., sequences, conductors)
• Data stores (e.g., CouchDB)
• Tests
• Deployment
• CLI
• General tooling
• Documentation

Types of changes

• Bug fix (generally a non-breaking change which closes an issue).
• Enhancement or new feature (adds new functionality).
• Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

• I signed an Apache CLA.
• I reviewed the style guides and followed the recommendations (Travis CI will check :).
• I added tests to cover my changes.
• My changes require further changes to the documentation.
• I updated the documentation where necessary.

[style95]

I pushed a new commit 3 hours ago, but the CI has not yet started..
It would severely degrade productivity.
If this is because of other jobs running and my job is waiting for it to be finished, we may need to find a way to deal with this.

[codecov-io]

Codecov Report

Merging #5042 (77535e8) into master (4babe39) will decrease coverage by 6.99%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5042      +/-   ##
==========================================
- Coverage   83.81%   76.81%   -7.00%     
==========================================
  Files         202      202              
  Lines        9818     9818              
  Branches      416      416              
==========================================
- Hits         8229     7542     -687     
- Misses       1589     2276     +687     

Impacted Files	Coverage Δ
...core/database/cosmosdb/RxObservableImplicits.scala	0.00% <0.00%> (-100.00%)	⬇️
...ore/database/cosmosdb/cache/CacheInvalidator.scala	0.00% <0.00%> (-100.00%)	⬇️
...e/database/cosmosdb/cache/ChangeFeedConsumer.scala	0.00% <0.00%> (-100.00%)	⬇️
...core/database/cosmosdb/CosmosDBArtifactStore.scala	0.00% <0.00%> (-95.48%)	⬇️
...sk/core/database/cosmosdb/CosmosDBViewMapper.scala	0.00% <0.00%> (-93.90%)	⬇️
...tabase/cosmosdb/cache/CacheInvalidatorConfig.scala	0.00% <0.00%> (-92.31%)	⬇️
...enwhisk/connector/kafka/KamonMetricsReporter.scala	0.00% <0.00%> (-83.34%)	⬇️
...e/database/cosmosdb/cache/KafkaEventProducer.scala	0.00% <0.00%> (-78.58%)	⬇️
...whisk/core/database/cosmosdb/CosmosDBSupport.scala	0.00% <0.00%> (-74.08%)	⬇️
...ore/database/azblob/AzureBlobAttachmentStore.scala	11.53% <0.00%> (-60.58%)	⬇️
... and 16 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4babe39...77535e8. Read the comment docs.

[rabbah]

Can we use GitHub actions at all to speed some things up?
I'm surprised old job don't get replaced by new ones - can you cancel them manually?

[style95]

@rabbah I reported the issue to the Travis team and they are investigating now.
I tried restarting the build by manual intervention but nothing changed.

[jiangpengcheng]

maybe try with github actions is a good option? I did tried with them and it worked well, additionally they are much faster than travis

[style95]

Now I only have this test.

[dgrove-oss]

There's some discussion of GitHub Actions over on builds@apache recently (http://mail-archives.us.apache.org/mod_mbox/www-builds/). It seems like the backlog to execute GHA is fairly long for repos in the Apache org, so not clear they will be any better than travis.

[rabbah]

It's possible to run GHA "on prem" (some other cloud). Would we be able to do that? I can arrange for us to have some compute cycles. Any discussion on the dev list if that's permissible/within ASF guidelines? Maybe we need a dev list post about this?

[style95]

Tests are failed again due to the rate limit on the Docker hub.

4.0: Pulling from library/redis, stderr: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit [marker:invoker_docker.pull_error:52736:52535]
    [2021-01-14T20:05:34.817Z] [ERROR] [#tid_sid_apiMgmt] [StandaloneOpenWhisk] Error starting Api Gatewayorg.apache.openwhisk.core.containerpool.docker.ProcessUnsuccessfulException: info: command was unsuccessful, code: 1 (unsuccessful), stdout: 4.0: Pulling from library/redis

IIRC, @rabbah requested an exemption to Docker, and seems it's not yet applied.

Regarding the GHA "on prem", it's essential to have a stable CI environment as it's not easy for contributors to debug an issue with his change if the reason for CI test failures varies every time.

With the indeterministic behavior of Travis CI, I am pro to GHA with the reliable underlying infrastructure.
And as @jiangpengcheng said, Travis CI is generally very slow due to limited resources.

And if we can have on-prem environments, we can even set up a pull-through-cache proxy of the Docker hub for CI tests.

[style95]

Finally, it passed all tests.
But I had to rerun some jobs manually and repeatedly to pass tests.

I observed many different reasons:

1. Docker rate limiting
2. CI tests heisenbug
3. Unexpected behavior of Travis's environment.
4. Travis's build does not start.

All of these should be addressed for better productivity.

Also, it relies on python2, we need to migrate to python3 as soon as possible.
Since there is some compatibility issue with python3, @jiangpengcheng `s work #5036 is also very important.

[style95]

We might want to pull all images in advance.