/test

Looks like a few problems

• whatever hw Travis is using for ppc64le seems to be underpowered/slow; both overall test timeouts and other parts of the CI are running much slower
• the new os: list conflicts with the other setting to run on darwin and tries to run a darwin/ppc64le pair, which obviously doesn't work.

@estesp: Updated the PR to exclude darwin/ppc64le pair. However one of the Travis CI is terminated because of The job exceeded the maximum time limit for jobs, and has been terminated. Should we exceed the timeout limits for ppc64le if incase the CI continues to exceed the time limit?

Looks like a few problems

• whatever hw Travis is using for ppc64le seems to be underpowered/slow; both overall test timeouts and other parts of the CI are running much slower

@estesp in the logs, I see that the following step is taking more time on ppc64le compare to x86:

The difference what I see in that particular script is that for x86 it is just download of the package from release section vs actual probuf compilation from the source which is causing the more delay here.

I see the recent version of protobuf publishing the package for the ppc64le architecture as well: https://github.com/protocolbuffers/protobuf/releases/download/v3.7.1/protoc-3.7.1-linux-ppcle_64.zip, so I'm wondering whether we can just bump up the protobuf version to v3.7.1 so same those ~21mins straightaway.

Build succeeded.

• containerd-build-arm64 : FAILURE in 1m 56s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 7m 59s (non-voting)

With the current code setup, the Travis CI is timing out on ppc64le at approx 50min

However on bumping the protobuf version to v3.7.1 , all CI's fail as recipe for target 'check-api-descriptors' fails

+ check-protos
+ check-api-descriptors
 M api/next.pb.txt
diff --git a/api/next.pb.txt b/api/next.pb.txt
index bd201ad..1f6d374 100755
--- a/api/next.pb.txt
+++ b/api/next.pb.txt
@@ -840,6 +840,7 @@ file {
     java_outer_classname: "FieldMaskProto"
     java_multiple_files: true
     go_package: "google.golang.org/genproto/protobuf/field_mask;field_mask"
+    cc_enable_arenas: true
     objc_class_prefix: "GPB"
     csharp_namespace: "Google.Protobuf.WellKnownTypes"
   }
- please run 'make protos' when making changes to proto files and check-in the generated descriptor file changes
Makefile:146: recipe for target 'check-api-descriptors' failed
make: *** [check-api-descriptors] Error 1

Would have to get @stevvooe's input on the 3.7.1 bump and whether that is possible with some simple changes, or recommended as a solution.

ping @stevvooe for input.

We can try the proto bump and to test, use a current client on the new daemon to make sure compatibility is there

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 07s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 51s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 16s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 10m 48s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 9m 17s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 45s (non-voting)

Looks like this made much more progress than before; but a cgroup test problem, and looking ahead (since the CRI tests went ahead and ran) there were 3 failures there.. one with portforward and a socat problem..maybe within the ppc64le vm setup?, and two others, which were the positive and negative tests of NoNewPrivs.

This is the cgroup failing test during make integration:

--- FAIL: TestDaemonCustomCgroup (0.16s)
    daemon_config_linux_test.go:251: custom cgroup path /sys/fs/cgroup/hugetlb/673537132 should exist, actually not
FAIL

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 23s (non-voting)

I bumped the builds for you

Thanks @crosbymichael and @estesp All checks have passed.

LGTM

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 19s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 20s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 50s (non-voting)

@crosbymichael could you please restart the CI or if I could get the permissions to do so, it would be more convenient. Thnx!

@nitkon i bumped the CI but the tests are still timing out so it looks like a real issue.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 17s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 27s (non-voting)

Codecov Report

Merging #3272 into master will decrease coverage by 4.32%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3272      +/-   ##
==========================================
- Coverage   44.18%   39.86%   -4.33%     
==========================================
  Files         124       86      -38     
  Lines       13751    11635    -2116     
==========================================
- Hits         6076     4638    -1438     
+ Misses       6744     6336     -408     
+ Partials      931      661     -270

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 f082134...d1b9ee5. Read the comment docs.

@crosbymichael @estesp: Finally all green! All the Travis CI tests have passed. It was failing due to some issues with Travis CI like the tests getting timed out due to networking issues, unrelated test failures etc. Apologies for so many re-pushes.

Times look good on the CI now, is it stable?

@crosbymichael : Looks fairly stable. https://travis-ci.org/nitkon/containerd/builds/568016813

LGTM