SUBMARINE-66. Improve TF config env JSON generator + tests

Uploaded SUBMARINE-66.003.patch from the corresponding jira. I hope yetus will pick it up, and it won't fail.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
64
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1063
trunk passed

-1
compile
20
hadoop-submarine-yarnservice-runtime in trunk failed.

-0
checkstyle
13
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
15
hadoop-submarine-yarnservice-runtime in trunk failed.

+1
shadedclient
651
branch has no errors when building and testing our client artifacts.

-1
javadoc
16
hadoop-submarine-yarnservice-runtime in trunk failed.

0
spotbugs
691
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
22
hadoop-submarine-yarnservice-runtime in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
14
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
compile
11
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
javac
11
hadoop-submarine-yarnservice-runtime in the patch failed.

-0
checkstyle
9
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
12
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
701
patch has no errors when building and testing our client artifacts.

-1
javadoc
11
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
findbugs
13
hadoop-submarine-yarnservice-runtime in the patch failed.

_ Other Tests _

-1
unit
13
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
asflicense
23
The patch does not generate ASF License warnings.

2760

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1132

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 4a7d130dea9f 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / aebac6d

Default Java
1.8.0_212

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/branch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-branch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/branch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/branch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/branch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/patch-mvninstall-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-patch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/patch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/patch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/patch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/artifact/out/patch-unit-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/testReport/

Max. process+thread count
412 (vs. ulimit of 5500)

modules
C: hadoop-submarine/hadoop-submarine-yarnservice-runtime U: hadoop-submarine/hadoop-submarine-yarnservice-runtime

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/1/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
93
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1293
trunk passed

-1
compile
19
hadoop-submarine-yarnservice-runtime in trunk failed.

-0
checkstyle
13
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
15
hadoop-submarine-yarnservice-runtime in trunk failed.

+1
shadedclient
774
branch has no errors when building and testing our client artifacts.

-1
javadoc
19
hadoop-submarine-yarnservice-runtime in trunk failed.

0
spotbugs
811
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
17
hadoop-submarine-yarnservice-runtime in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
11
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
compile
12
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
javac
12
hadoop-submarine-yarnservice-runtime in the patch failed.

-0
checkstyle
9
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
11
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
836
patch has no errors when building and testing our client artifacts.

-1
javadoc
14
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
findbugs
13
hadoop-submarine-yarnservice-runtime in the patch failed.

_ Other Tests _

-1
unit
15
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
asflicense
32
The patch does not generate ASF License warnings.

3302

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1132

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 269dab8aef07 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / d086d05

Default Java
1.8.0_222

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/branch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-branch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/branch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/branch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/branch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/patch-mvninstall-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-patch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/patch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/patch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/patch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/artifact/out/patch-unit-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/testReport/

Max. process+thread count
306 (vs. ulimit of 5500)

modules
C: hadoop-submarine/hadoop-submarine-yarnservice-runtime U: hadoop-submarine/hadoop-submarine-yarnservice-runtime

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/2/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
42
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1101
trunk passed

-1
compile
19
hadoop-submarine-yarnservice-runtime in trunk failed.

-0
checkstyle
12
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
14
hadoop-submarine-yarnservice-runtime in trunk failed.

+1
shadedclient
659
branch has no errors when building and testing our client artifacts.

-1
javadoc
16
hadoop-submarine-yarnservice-runtime in trunk failed.

0
spotbugs
691
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
14
hadoop-submarine-yarnservice-runtime in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
11
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
compile
9
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
javac
9
hadoop-submarine-yarnservice-runtime in the patch failed.

-0
checkstyle
7
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
10
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
742
patch has no errors when building and testing our client artifacts.

-1
javadoc
14
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
findbugs
13
hadoop-submarine-yarnservice-runtime in the patch failed.

_ Other Tests _

-1
unit
16
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
asflicense
38
The patch does not generate ASF License warnings.

2838

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1132

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux cca727a007f4 4.4.0-157-generic #185-Ubuntu SMP Tue Jul 23 09:17:01 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 70b4617

Default Java
1.8.0_212

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/branch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-branch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/branch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/branch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/branch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/patch-mvninstall-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-patch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/patch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/patch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/patch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/artifact/out/patch-unit-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/testReport/

Max. process+thread count
412 (vs. ulimit of 5500)

modules
C: hadoop-submarine/hadoop-submarine-yarnservice-runtime U: hadoop-submarine/hadoop-submarine-yarnservice-runtime

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/3/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
41
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1060
trunk passed

-1
compile
21
hadoop-submarine-yarnservice-runtime in trunk failed.

-0
checkstyle
12
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
14
hadoop-submarine-yarnservice-runtime in trunk failed.

+1
shadedclient
645
branch has no errors when building and testing our client artifacts.

-1
javadoc
15
hadoop-submarine-yarnservice-runtime in trunk failed.

0
spotbugs
677
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
14
hadoop-submarine-yarnservice-runtime in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
11
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
compile
11
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
javac
11
hadoop-submarine-yarnservice-runtime in the patch failed.

-0
checkstyle
6
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
11
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
735
patch has no errors when building and testing our client artifacts.

-1
javadoc
11
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
findbugs
12
hadoop-submarine-yarnservice-runtime in the patch failed.

_ Other Tests _

-1
unit
13
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
asflicense
25
The patch does not generate ASF License warnings.

2748

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1132

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 998f5fbc2cfb 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 397a563

Default Java
1.8.0_212

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/branch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-branch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/branch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/branch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/branch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/patch-mvninstall-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-patch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/patch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/patch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/patch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/artifact/out/patch-unit-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/testReport/

Max. process+thread count
447 (vs. ulimit of 5500)

modules
C: hadoop-submarine/hadoop-submarine-yarnservice-runtime U: hadoop-submarine/hadoop-submarine-yarnservice-runtime

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/4/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
85
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1146
trunk passed

-1
compile
26
hadoop-submarine-yarnservice-runtime in trunk failed.

-0
checkstyle
11
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
17
hadoop-submarine-yarnservice-runtime in trunk failed.

+1
shadedclient
698
branch has no errors when building and testing our client artifacts.

-1
javadoc
15
hadoop-submarine-yarnservice-runtime in trunk failed.

0
spotbugs
730
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
14
hadoop-submarine-yarnservice-runtime in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
14
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
compile
9
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
javac
9
hadoop-submarine-yarnservice-runtime in the patch failed.

-0
checkstyle
8
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
10
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
725
patch has no errors when building and testing our client artifacts.

-1
javadoc
12
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
findbugs
11
hadoop-submarine-yarnservice-runtime in the patch failed.

_ Other Tests _

-1
unit
12
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
asflicense
24
The patch does not generate ASF License warnings.

2927

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1132

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 518cfcf870f9 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / e356e4f

Default Java
1.8.0_222

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/branch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-branch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/branch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/branch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/branch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/patch-mvninstall-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-patch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/patch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/patch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/patch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/artifact/out/patch-unit-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/testReport/

Max. process+thread count
415 (vs. ulimit of 5500)

modules
C: hadoop-submarine/hadoop-submarine-yarnservice-runtime U: hadoop-submarine/hadoop-submarine-yarnservice-runtime

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/5/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
40
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1128
trunk passed

-1
compile
16
hadoop-submarine-yarnservice-runtime in trunk failed.

-0
checkstyle
12
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
13
hadoop-submarine-yarnservice-runtime in trunk failed.

+1
shadedclient
643
branch has no errors when building and testing our client artifacts.

-1
javadoc
14
hadoop-submarine-yarnservice-runtime in trunk failed.

0
spotbugs
671
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
13
hadoop-submarine-yarnservice-runtime in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
10
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
compile
10
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
javac
10
hadoop-submarine-yarnservice-runtime in the patch failed.

-0
checkstyle
8
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
11
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
730
patch has no errors when building and testing our client artifacts.

-1
javadoc
14
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
findbugs
13
hadoop-submarine-yarnservice-runtime in the patch failed.

_ Other Tests _

-1
unit
13
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
asflicense
25
The patch does not generate ASF License warnings.

2814

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1132

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux b9485cc74459 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 094d736

Default Java
1.8.0_222

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/branch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-branch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/branch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/branch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/branch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/patch-mvninstall-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-patch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/patch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/patch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/patch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/artifact/out/patch-unit-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/testReport/

Max. process+thread count
446 (vs. ulimit of 5500)

modules
C: hadoop-submarine/hadoop-submarine-yarnservice-runtime U: hadoop-submarine/hadoop-submarine-yarnservice-runtime

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/6/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
67
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1064
trunk passed

-1
compile
15
hadoop-submarine-yarnservice-runtime in trunk failed.

-0
checkstyle
12
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
13
hadoop-submarine-yarnservice-runtime in trunk failed.

+1
shadedclient
637
branch has no errors when building and testing our client artifacts.

-1
javadoc
13
hadoop-submarine-yarnservice-runtime in trunk failed.

0
spotbugs
665
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
13
hadoop-submarine-yarnservice-runtime in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
10
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
compile
10
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
javac
10
hadoop-submarine-yarnservice-runtime in the patch failed.

-0
checkstyle
11
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
11
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
700
patch has no errors when building and testing our client artifacts.

-1
javadoc
12
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
findbugs
11
hadoop-submarine-yarnservice-runtime in the patch failed.

_ Other Tests _

-1
unit
11
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
asflicense
24
The patch does not generate ASF License warnings.

2724

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1132

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux d955050fcf1a 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 69ddb36

Default Java
1.8.0_222

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/branch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-branch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/branch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/branch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/branch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/patch-mvninstall-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-patch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/patch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/patch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/patch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/artifact/out/patch-unit-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/testReport/

Max. process+thread count
446 (vs. ulimit of 5500)

modules
C: hadoop-submarine/hadoop-submarine-yarnservice-runtime U: hadoop-submarine/hadoop-submarine-yarnservice-runtime

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/7/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Still no good jenkins build...
I hope after Submarine got moved to a separate repository jenkins will be fixed as well.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
80
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1213
trunk passed

-1
compile
21
hadoop-submarine-yarnservice-runtime in trunk failed.

-0
checkstyle
14
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
15
hadoop-submarine-yarnservice-runtime in trunk failed.

+1
shadedclient
788
branch has no errors when building and testing our client artifacts.

-1
javadoc
23
hadoop-submarine-yarnservice-runtime in trunk failed.

0
spotbugs
830
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
17
hadoop-submarine-yarnservice-runtime in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
12
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
compile
12
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
javac
12
hadoop-submarine-yarnservice-runtime in the patch failed.

-0
checkstyle
11
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
11
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
855
patch has no errors when building and testing our client artifacts.

-1
javadoc
13
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
findbugs
12
hadoop-submarine-yarnservice-runtime in the patch failed.

_ Other Tests _

-1
unit
12
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
asflicense
25
The patch does not generate ASF License warnings.

3239

Subsystem
Report/Notes

Docker
Client=19.03.0 Server=19.03.0 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1132

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 675b51c8750a 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 3329257

Default Java
1.8.0_212

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/branch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-branch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/branch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/branch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/branch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/patch-mvninstall-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-patch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/patch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/patch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/patch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/artifact/out/patch-unit-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/testReport/

Max. process+thread count
307 (vs. ulimit of 5500)

modules
C: hadoop-submarine/hadoop-submarine-yarnservice-runtime U: hadoop-submarine/hadoop-submarine-yarnservice-runtime

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/8/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
47
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1136
trunk passed

-1
compile
32
hadoop-submarine-yarnservice-runtime in trunk failed.

-0
checkstyle
16
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
18
hadoop-submarine-yarnservice-runtime in trunk failed.

+1
shadedclient
707
branch has no errors when building and testing our client artifacts.

-1
javadoc
24
hadoop-submarine-yarnservice-runtime in trunk failed.

0
spotbugs
752
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
18
hadoop-submarine-yarnservice-runtime in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
15
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
compile
13
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
javac
13
hadoop-submarine-yarnservice-runtime in the patch failed.

-0
checkstyle
10
The patch fails to run checkstyle in hadoop-submarine-yarnservice-runtime

-1
mvnsite
12
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
whitespace
1
The patch has no whitespace issues.

+1
shadedclient
756
patch has no errors when building and testing our client artifacts.

-1
javadoc
19
hadoop-submarine-yarnservice-runtime in the patch failed.

-1
findbugs
14
hadoop-submarine-yarnservice-runtime in the patch failed.

_ Other Tests _

-1
unit
15
hadoop-submarine-yarnservice-runtime in the patch failed.

+1
asflicense
30
The patch does not generate ASF License warnings.

2997

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1132

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 7d6cb8ada9cf 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 915cbc9

Default Java
1.8.0_222

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/branch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-branch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/branch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/branch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/branch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/patch-mvninstall-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/patch-compile-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out//home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-1132/out/maven-patch-checkstyle-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/patch-mvnsite-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/patch-javadoc-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/patch-findbugs-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/artifact/out/patch-unit-hadoop-submarine_hadoop-submarine-yarnservice-runtime.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/testReport/

Max. process+thread count
411 (vs. ulimit of 5500)

modules
C: hadoop-submarine/hadoop-submarine-yarnservice-runtime U: hadoop-submarine/hadoop-submarine-yarnservice-runtime

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1132/9/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

I close this PR as Submarine will be moved to a separate repository soon.


Add file persistence store interface

Fixes #59

Codecov Report

Merging #62 (98e6681) into main (08bcd0b) will increase coverage by 0.94%.
The diff coverage is 98.31%.

@@            Coverage Diff             @@
##             main      #62      +/-   ##
==========================================
+ Coverage   80.34%   81.29%   +0.94%
==========================================
  Files          38       40       +2
  Lines        4870     5021     +151
  Branches      854      871      +17
==========================================
+ Hits         3913     4082     +169
+ Misses        767      747      -20
- Partials      190      192       +2

Impacted Files
Coverage Δ

shc/log/file_persistence.py
98.31% <98.31%> (ø)

example/knx_specifics.py
84.37% <0.00%> (ø)

shc/log/generic.py
85.30% <0.00%> (+0.47%)
:arrow_up:

shc/web/log_widgets.py
94.44% <0.00%> (+1.85%)
:arrow_up:

example/ui_logging_showcase.py
94.28% <0.00%> (+2.85%)
:arrow_up:

shc/interfaces/knx.py
60.14% <0.00%> (+15.94%)
:arrow_up:

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 08bcd0b...98e6681. Read the comment docs.


OutputContainer should show a overall menu and a menu for each content cell

A OutputContainer should show a overall menu and a menu for each content cell

remaining part is #1002


Track Character Motivations Through Time

🚀 Feature Request
📝 Description

Character motivations should be moved from scenes to story events.
✨ Describe the solution you'd like

Currently, scenes keep track of character motivations, but it would make more sense for story events to do so.  Characters would have a motivation that can be changed within a story event.  Each subsequent story event that includes that character would then inherit that motivation, up to the next story event that changes that character's motivation again.  This is currently how scenes behave, but it would make more sense for it to happen in story events.
The difference between scenes and story events handling this is that scenes are ordered and cannot share a position in the story.  Story events can happen at the same time, so there would need to be a soft requirement that a character cannot be included in two separate story events at the same time.  Instead of outright preventing the user from doing this, the system could automatically detect such a scenario and warn the user that they have a potential logical problem in their story.  They can then choose to either: combine the two story events into one, remove the character from one of the story events, or ignore the warning.
This also means that a ramifications report would need to exist for story events being moved or removed because they could impact the inherited motivations of characters in other story events.
✍ Describe alternatives you've considered
Keeping the motivation in scenes doesn't make sense anymore since a character's motivation "exists" independently of if the audience is made aware of that motivation.

Copied from Discord:
"I would love to play with this feature by taking a longform story like Better Call Saul, plugging in all the story events where, say, Kim Wexler is present, making notes of the actions, but also tracking her motivation from event to event. I feel like I'd better understand her character, which is an awesome feature of our program
How would you handle a flashback? There's a scene in Season 5 BCS where a young Kim walks home from school because her mother's drunk driving. Her motivation is obviously paralleled by her motivations in the actual story time, but it kind of breaks the chain from the previous story event and the next one which are chronological story time. It's more of the author's motivation of what the story accomplishes by putting this flashback inbetween two chronological story events
I would say a GOOD story, when it does a flashback, is showing a time when the character had a similar motivation when they were younger, to give dimension to that motivation, so it could still make sense to inherit the previous motivation. But it could also be a flashback when they had an OPPOSING motivation, and by the end they wound up having the motivation from the previous story event, so it wouldn't make sense to inherit the motivation, but it would still be continuous because the two chronological story events would still respectively end and begin with the same motivation.
E.g. *
Congruent Story events with flashback*
Story Event 1
Kim wants to be autonomous despite challenge from her employers.
Story Event 2 (Flashback)
Young Kim wants to be autonomous despite challenge from her mother.
Story Event 3
Kim challenges her employers to bolster her autonomy.
Incongruent story events with flashback
Story Event 1
Jimmy ponders how to cut corners with a client to win a case, involving taking advantage of someone.
Story Event 2 (Flashback)
A young innocent Jimmy sees his father get taken advantage of at his dad's old shop. Jimmy learns he has to be a "wolf not a sheep"
Story Event 3
Jimmy acts like a wolf in order to win the case with his client by taking advantage of someone."


Module configuration refactoring

The proposed changes are mostly aimed to improve overall code readability.
As a bonus, 2ae2a10 introduces a little feature of extending connector banner message with a total number of loaded rules with breakdown by rule source, e.g.:
2018/11/30 08:20:22 [notice] 9116#9116: ModSecurity-nginx v1.0.0 (rules loaded inline/local/remote: 0/1634/0)

Hi @defanator,
The only thing that is crucial in terms of Rules merge, is the fact that somehow they have to respect the hierarchy in order to reduce the memory footprint. Two different virtual hosts can make usage of a rules set loaded in server configuration, instead of load two different copies of the rules into memory.
In the effort SpiderLabs/ModSecurity#1970 we are trying to allow the rules to be reloaded is run time, also, we are going to reduce the memory usage by replacing some textual tags with binary properties (good for memory and cpu) and shared_pointers instead of string repetition, pretty simple change that will produce a great result. But, yet, better to load the rules into memory only once, than have it loaded multiple times.
With that said, i think your patch is fine :) Indeed, it does improved the readability. The amount of loaded rules is amazing.

@zimmerle rules merging hasn't changed with the proposed PR, I've just removed duplicate parts of code (i.e. merge_srv_conf and merge_loc_conf were actually doing the same stuff).
In regards to the dynamic modsecurity configuration management, I definitely like the idea. Currently one has to reload nginx by sending SIGHUP to master process after modsecurity configuration has changed; despite such approach can work without breaking live traffic (thanks to nginx' ability to gracefully pass incoming load to new set of workers), avoiding workers restart is a way better thing. It may bring a number of challenges though.

@zimmerle in regards to memory footprint - yes, I'm pretty sure (lib)modsecurity (and/or connector modules) should be smart enough to detect whether the exactly same set of rules is being loaded for multiple entities (servers / locations / virtual hosts / you name it), and avoid any sort of duplicates.
I can imagine how to achieve this with loading rules from file (e.g. you can store and check SHA sums / modification times of a conf and its includes). Using remote sources may require additional checks like passing "If-Modified" and checking response codes, etc. Anyway, there is a room for improvements.

Merged! ;) thanks!


Upgrade: simdjson.

:tada: This PR is included in version 0.2.7 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[Feature]: Socks proxy support

Description

Cannot directly connect to the server in our organization but ssh -D gives us an easy way to obtain a SOCKS proxy.

Suggested Solution
It will be great to support the SOCKS connection.
Alternatives
No response
Additional Context
No response

you want to make a PR?


do you have plan release code?

Hi @PyNancy, thank you for your interest in this work! Yes, we plan to release the code in the coming weeks. Please stay tuned!

@ldkong1205  thanks for your reply, i am looking forward your nice work.

Hi, also looking forward for your code release, about how long it will takes?

Hi, also looking forward for your code release, about how long it will takes?

Hi @faikit, thank you for your interest, and sorry for the late reply! We are a bit busy lately. This codebase is planned to have an update next month. The major components, such as the support of different datasets and backbones, will be added in around early December. We will let you know once things are ready. Thanks!

Hello @ldkong1205 I have gone through your work and is really interesting. I have seen your interest in Point cloud translation of SynLiDAR to semanticKitti in the paper "Transfer learning from synthetic to real LiDAR point cloud for semantic segmentation" . I am also doing research on the same topic. Please let me know if you have got any source code for PCT. That would be really helpful if you can share your view on the same

Hello @ldkong1205 I have gone through your work and is really interesting. I have seen your interest in Point cloud translation of SynLiDAR to semanticKitti in the paper "Transfer learning from synthetic to real LiDAR point cloud for semantic segmentation" . I am also doing research on the same topic. Please let me know if you have got any resources for implementation code for PCT. That would be really helpful if you can share your view on the same

Hi @vijayM12, thank you for your interest in our work!
As you said, we intended to test the sim2real setting with LaserMix. However, the source code for PCT in the mentioned paper has not been released yet and we actually do not have the plan to re-implement their idea. We are seeking alternatives for achieving this now and we will let you know once we figure it out. Thanks!

Hello @ldkong1205 I have gone through your work and is really interesting. I have seen your interest in Point cloud translation of SynLiDAR to semanticKitti in the paper "Transfer learning from synthetic to real LiDAR point cloud for semantic segmentation" . I am also doing research on the same topic. Please let me know if you have got any resources for implementation code for PCT. That would be really helpful if you can share your view on the same

Hi @vijayM12, thank you for your interest in our work!
As you said, we intended to test the sim2real setting with LaserMix. However, the source code for PCT in the mentioned paper has not been released yet and we actually do not have the plan to re-implement their idea. We are seeking alternatives for achieving this now and we will let you know once we figure it out. Thanks!

Hello @ldkong1205 Could you please release the source code for LaserMix as soon as possible. It would help me understand better to implement sim2Real

Hello @ldkong1205 I have gone through your work and is really interesting. I have seen your interest in Point cloud translation of SynLiDAR to semanticKitti in the paper "Transfer learning from synthetic to real LiDAR point cloud for semantic segmentation" . I am also doing research on the same topic. Please let me know if you have got any resources for implementation code for PCT. That would be really helpful if you can share your view on the same

Hi @vijayM12, thank you for your interest in our work!
As you said, we intended to test the sim2real setting with LaserMix. However, the source code for PCT in the mentioned paper has not been released yet and we actually do not have the plan to re-implement their idea. We are seeking alternatives for achieving this now and we will let you know once we figure it out. Thanks!

Hello @ldkong1205 Could you please release the source code for LaserMix as soon as possible. It would help me understand better to implement sim2Real

Hi @vijayM12, sure! As promised in the previous reply, the code and checkpoints for reproducing our results will be available soon. We are now retouching the codebase and collecting the logs and checkpoints. Please stay tuned~

Hello @ldkong1205 I have gone through your work and is really interesting. I have seen your interest in Point cloud translation of SynLiDAR to semanticKitti in the paper "Transfer learning from synthetic to real LiDAR point cloud for semantic segmentation" . I am also doing research on the same topic. Please let me know if you have got any resources for implementation code for PCT. That would be really helpful if you can share your view on the same

Hi @vijayM12, thank you for your interest in our work!
As you said, we intended to test the sim2real setting with LaserMix. However, the source code for PCT in the mentioned paper has not been released yet and we actually do not have the plan to re-implement their idea. We are seeking alternatives for achieving this now and we will let you know once we figure it out. Thanks!

Hello @ldkong1205 Could you please release the source code for LaserMix as soon as possible. It would help me understand better to implement sim2Real

Hi @vijayM12, sure! As promised in the previous reply, the code and checkpoints for reproducing our results will be available soon. We are now retouching the codebase and collecting the logs and checkpoints. Please stay tuned~

Ok Thank you

Ok thanks
Regards,
Vijaya Phanindra Kumar M
On Sat, Dec 3, 2022, 7:50 AM Lingdong Kong @.***> wrote:

Hello @ldkong1205 https://github.com/ldkong1205 I have gone through
your work and is really interesting. I have seen your interest in Point
cloud translation of SynLiDAR to semanticKitti in the paper "Transfer
learning from synthetic to real LiDAR point cloud for semantic
segmentation" . I am also doing research on the same topic. Please let me
know if you have got any resources for implementation code for PCT. That
would be really helpful if you can share your view on the same
Hi @vijayM12 https://github.com/vijayM12, thank you for your interest
in our work!
As you said, we intended to test the sim2real setting with LaserMix.
However, the source code for PCT in the mentioned paper has not been
released yet and we actually do not have the plan to re-implement their
idea. We are seeking alternatives for achieving this now and we will let
you know once we figure it out. Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/ldkong1205/LaserMix/issues/1#issuecomment-1336015759,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWICPGAAALTKRMYVIASA6R3WLKU5PANCNFSM6AAAAAAQL73KDE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hello @ldkong1205，congratulation to you for the LaserMix is accepted to CVPR2023.
Could you release the source code for LaserMix? It will help us to understand LaserMix and follow this great work.

Hi @zhairf, thanks for your interest in this work!
As mentioned here (https://github.com/ldkong1205/LaserMix/issues/6), an enhanced version is coming on the way. We are running experiments now, benchmarking different backbones under different semi-supervised settings (random, sequential, etc.). The new code and checkpoints will be made publicly available.

We are closing this issue now. Feel free to open a new one if you encounter any problems.


IGNITE-23970 Sql. Extend usage of HashJoin

https://issues.apache.org/jira/browse/IGNITE-23970

Thank you for submitting the pull request.
To streamline the review process of the patch and ensure better code quality
we ask both an author and a reviewer to verify the following:
The Review Checklist

[ ] Formal criteria: TC status, codestyle, mandatory documentation. Also make sure to complete the following:
- There is a single JIRA ticket related to the pull request.
- The web-link to the pull request is attached to the JIRA ticket.
- The JIRA ticket has the Patch Available state.
- The description of the JIRA ticket explains WHAT was made, WHY and HOW.
- The pull request title is treated as the final commit message. The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
[ ] Design: new code conforms with the design principles of the components it is added to.
[ ] Patch quality: patch cannot be split into smaller pieces, its size must be reasonable.
[ ] Code quality: code is clean and readable, necessary developer documentation is added if needed.
[ ] Tests code quality: test set covers positive/negative scenarios, happy/edge cases. Tests are effective in terms of execution time and resources.

Notes

Apache Ignite Coding Guidelines

not related to this issue, just think - can we extend usage a bit more, for conditions like: join on c11 = c21 OR c12 = c22 ?

can we extend usage a bit more, for conditions like: join on c11 = c21 OR c12 = c22 ?

@zstan such a case requires significant redesign of the HashJoinNode, since we would need to prepare several materialized parts for every disjunctive part, and do several looks up in every part. Considering required effort, I'm not sure it's priority-one optimization.


Added a default status 200 for incoming requests from facebook

The 200 is required to let facebook know we received the message and we are processing it. Without the 200, your bot is sometimes flooded by repeated requests from Facebook for the same message.

I think we're already responding with HTTP 200 though; it is the default of Rack::Response.initialize. Am I missing something?

I'm sorry, I read the doc wrong.

No worries, @alexandrecardinal! :smile:


Regarding coolCoast and heatCoast values and their meaning

Sorry if someone already added this. It was requested in the READ ME

Thank you!  Will update.   These fields will be in 0.1.3 - looks like our docs are ahead of the release…

Docs have been updated for 0.1.3 release - coming out this upcoming week


Terragrunt Custom retryable_errors Not Matching

Hey,
I've defined a custom retryable_errors block like so
retryable_errors = [
  "(?s).*Error: error listing tags for resource.*"
]

Inside of my terragrunt.hcl file.
Because I occasionally see this error:
Error: error listing tags for resource (<AWS ARN>): CacheClusterNotFound: <CLUSTER NAME> is either not present or not available.
	status code: 404, request id: <REQUEST ID>

When creating Elasticache Clusters (it appears to be some sort of eventual consistency error, because the resource does exist)
However terragrunt run-all apply never retries on that error.
Have I misunderstood how the Regex should be written, or am I doing something else wrong?

Hm, your regex seems fine... Could you share the full log output where you get that error and Terragrunt's logging around it? And perhaps turn up the log level?
Also, what version of Terragrunt are you on?

Hey,
Thanks for the reply,

We're using terragrunt 0.28.2
We have debug logging turned on already, this is the logging around the error:

aws_elasticache_replication_group.redis: Still creating... [5m30s elapsed]
aws_elasticache_replication_group.redis: Still creating... [5m30s elapsed]
aws_elasticache_replication_group.redis: Still creating... [5m30s elapsed]
aws_elasticache_replication_group.redis: Still creating... [5m30s elapsed]

Error: error listing tags for resource (arn:aws:elasticache:us-east-1:<AWS ACCOUNT ID>:cluster:<CLUSTER_NAME>): CacheClusterNotFound: <CLUSTER_NAME> is either not present or not available.
	status code: 404, request id: <REQUEST ID>

time=2021-03-31T07:22:59Z level=info msg=Module /srv/actions-runner/_work/terragrunt/terragrunt/dev/us-east-1/reference/<PRODUCT NAME>/redislock/02 has finished with an error: Hit multiple errors:
Hit multiple errors:
exit status 1 prefix=[/srv/actions-runner/_work/terragrunt/terragrunt/dev/us-east-1/reference/<PRODUCT NAME>/redislock/02]

Strange. It does seem like a bug. Have you tried simplifying the regex to see if that would help?
We're a bit buried right now, so we might not be able to dig in for a bit. If anyone has some time available, a PR is very welcome.

I could not repro this with terragrunt 0.28.2.
Since it's hard to induce the exact failures described in the ticket, I used this simple example:
$ cat main.tf
resource "null_resource" "example" {
  triggers = {
    always_recreate = timestamp()
  }

provisioner "local-exec" {
    command = "echo 'aws_elasticache_replication_group.redis: Still creating...\n\nError: error listing tags for resource (arn:aws:elasticache:us-east-1:<AWS ACCOUNT ID>:cluster:<CLUSTER_NAME>): CacheClusterNotFound: <CLUSTER_NAME> is either not present or not available. \n	status code: 404, request id: <REQUEST ID> \n' && exit 1"
  }
}

$ cat terragrunt.hcl
retryable_errors = [
  "(?s).*Error: error listing tags for resource.*"
]

Running terragrunt run-all apply results in three retries before it finally gives up, which is the expected behavior.
Regex matching also works as expected, in the example above the regex matches against the error string.

Hey,
Thanks for the reply, we couldn't get that Regex to work for us still, however my colleague added these additional Regexes and now one of them does match the error and triggers the retries we needed:
  "(?s).*Error: error listing tags for resource.*",
  "(?s).*CacheClusterNotFound.*",
  "(?s).*elasticache.*"

Still not sure why the original one doesn't match, but this is a perfectly fine workaround for us, so feel free to close this now :)
Thanks everyone for the help.

Thanks for closing the loop @AaronKalair! Let us know if you still hit any issues, in the meantime I'll close this bug.


Curl "undefined symbol: curl_url_cleanup" issue on test-docker-ubuntu1804-armv8-1

Failure Links:
https://trss.adoptopenjdk.net/output/build?id=602d97e35730424dbc7f9207
https://trss.adoptopenjdk.net/output/build?id=602e3a8d5730424dbc808e9a
https://trss.adoptopenjdk.net/output/build?id=602e3a8d5730424dbc808e99

Grinder Link:
https://ci.adoptopenjdk.net/job/Grinder/parambuild/?TARGET=sanity.openjdk&SDK_RESOURCE=upstream&TEST_FLAG=&UPSTREAM_TEST_JOB_NAME=&DOCKER_REQUIRED=false&ACTIVE_NODE_TIMEOUT=0&EXTRA_DOCKER_ARGS=&VENDOR_TEST_DIRS=&TKG_OWNER_BRANCH=AdoptOpenJDK%3Amaster&PLATFORM=aarch64_linux&KEEP_REPORTDIR=true&PERSONAL_BUILD=false&ADOPTOPENJDK_REPO=https%3A%2F%2Fgithub.com%2FAdoptOpenJDK%2Fopenjdk-tests.git&LABEL=test-docker-ubuntu1804-armv8-1&EXTRA_OPTIONS=&CUSTOMIZED_SDK_URL=&BUILD_IDENTIFIER=&ADOPTOPENJDK_BRANCH=master&ARTIFACTORY_SERVER=&KEEP_WORKSPACE=false&JDK_VERSION=8&USER_CREDENTIALS_ID=&ITERATIONS=1&VENDOR_TEST_REPOS=&JDK_REPO=https%3A%2F%2Fgithub.com%2Fibmruntimes%2Fopenj9-openjdk-jdk8&RELEASE_TAG=&OPENJ9_BRANCH=master&OPENJ9_SHA=&JCK_GIT_REPO=&VENDOR_TEST_BRANCHES=&UPSTREAM_JOB_NAME=build-scripts%2Fjobs%2Fjdk8u%2Fjdk8u-linux-aarch64-openj9&OPENJ9_REPO=https%3A%2F%2Fgithub.com%2Feclipse%2Fopenj9.git&CUSTOM_TARGET=&VENDOR_TEST_SHAS=&JDK_BRANCH=openj9&LABEL_ADDITION=&ARTIFACTORY_REPO=&ARTIFACTORY_ROOT_DIR=&UPSTREAM_TEST_JOB_NUMBER=&DOCKERIMAGE_TAG=&JDK_IMPL=openj9&SSH_AGENT_CREDENTIAL=&AUTO_DETECT=true&TKG_SHA=&CUSTOMIZED_SDK_URL_CREDENTIAL_ID=&NUM_MACHINES=&OPENJDK_SHA=&BUILD_LIST=openjdk&UPSTREAM_JOB_NUMBER=214&TIME_LIMIT=10&JVM_OPTIONS=&PARALLEL=None

Symptom:

curl: symbol lookup error: curl: undefined symbol: curl_url_cleanup

Appears 100% reproducible, and specific to this machine so far. Tests on other aarch64 machines don't see this issue.

Cause:

This website suggests that this issue is a hazard of building your own curl.

Solution
That same website recommends running "sudo ldconfig" after building, to resolve the issue. It seems we currently run ldconfig in the ansible scripts, but only for x86_64, and only for the OpenSSL task on Unix. Should we be rebuilding the linker cache after curl setup too?

Perhaps we should start by removing the test tag from this machine. Raising the question on Slack.

Machine disabled. Also, Stewart suspects this may be caused by a custom-built curl that was created in an attempt to get around another issue on the ThunderX machines.


Describe the bug

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional numbers
The number 345567

describe the bug


plutonium core steal objective

About the PR
added plutonium core steal objective for tators and everything it needs
if you have the objective you can get a susbox containing the gear for free in the new Objectives tab of the uplink
you can deconstruct, and reconstruct, nukes to and from a disarmed state
once you get the plutonium core you can put it into a nuke core container and close it, then it cannot be opened again (unless you emag it, the intention being if theres traitors and nukies at the same time its still somewhat possible for nukies to get the core out and rebuild the nuke. can also go the other way around of a traitor yoinking the nukies' core)
depends on #26779
Why / Balance
less boring steal objectives that are just yoink/fishbomb someone for their gear, and more like mission impossible
Technical details

new ObjectiveUnlockCondition and StoreUnlocker pair added that let a listing only be accessible to someone that has an objective unlocking it
added SealableCabinet that prevents opening the nuke core container when sealed

Media
https://github.com/space-wizards/space-station-14/assets/39013340/0f007bd2-f133-4915-9426-a93e37874d77

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes
no
Changelog
:cl:

add: Traitors can now be assigned to deconstruct the station's nuke for its precious plutonium core.
add: Added the Objectives category in the uplink with a Core Extraction Toolbox for deconstructing said nuke.

demon core

based

it is.

i didnt have a geiger counter which makes the sound, it does 4 rads/s

that was never a thing

Closed due to feature freeze May 10th-June 14th. Comment to have it reopen after this.

open

there was literally an 11 hour window where this was merged. love it or hate it, that's pretty funny.


Why do all ADTypes have Auto in their names?

It looks like all exported types have Auto in their names. Why "Auto" and why not drop this prefix?
I feel like this implies the existence of some "Manual" AD backends.
https://github.com/SciML/ADTypes.jl/blob/59ded48442fb3806f87fd65fdeb40a681af68b2e/src/ADTypes.jl#L225-L239

I think it stands for autodiff but I might be wrong

It just felt nice when we named these. Also dropping them would make it identical to the module names hence not a valid identifier

Tbh I find it quite logical so I am not sure, I interpret it as - "Automatically use Zygote". Naming can be quite subjective so unless there's a technical reason for not liking this I don't see this conversation reaching a conclusion 😅

I interpret it as - "Automatically use Zygote".

As suggested on Slack by @mcabbott, adding this to the docstrings and mentioning that these types come from ADTypes (not everyone is aware of parentmodule) is probably enough to avoid the issue.

It just felt nice when we named these. Also dropping them would make it identical to the module names hence not a valid identifier

That's the big reason. You can't just call it Zygote() otherwise lots of stuff happens, so what do you append it with? Auto for automatic differentiation or automatic choice made sense. We can bikeshed names if we want, ultimately it's not a big deal if there's a deprecation path for it. But if you do the change then I expect that you update all downstream code, SciML and beyond, because it's part of the policy to follow through with breaking changes.


Feature: CSES - Edit Distance

Is your feature request related to a problem? Please describe.
Yes. It is related to the CSES problem set.

The edit distance between two strings is the minimum number of operations required to transform one string into the other.
The allowed operations are:
->Add one character to the string.
->Remove one character from the string.
->Replace one character in the string.
Describe the solution you'd like
I would like to write a solution in cpp language

I would be using dynamic programming approach to solve the problem.
Describe alternatives you've considered
I had considered using greedy, but that would not work in this case as this problem has overlapping subproblems and optimal substructure, hence dynamic programming approach would be best.

Additional context

@keshavsingh4522 sir, kindly assign me the above issue. I want to work in cpp language. Please assign me. Thank you.

Hello, I am interested to work on  this issue.
Could you please assign it to me.


international data: incidence, mortality, testing

might reopen if interest is shown.
corona report has the numbers already (kind of)

might reopen if interest is shown.
corona report has the numbers already (kind of)


Output chained matchers description

Subject of the issue
I've created a custom matcher which allows to chain other matchers against a computed value :
matcher :have_html_body do
  chain :to, :other_matcher

  match do |actual|
    @actual = actual.parsed_body

    html_body_valid?(@actual) && other_matcher_matches?(@actual)
  end

  def other_matcher_matches?(actual)
    other_matcher.nil? || other_matcher.matches?(actual)
  end
end

I can then chain any matchers to match the parsed body :
expect(response).to have_html_body.to include("Hello World")
expect(response).to have_html_body.to match(/hello/)
expect(response).to have_html_body.to have_selector("#test", text: "Hello World")

It works fine, but descriptions are cumbersome :
is expected to have html body to #<RSpec::Matchers::BuiltIn::Include:0x0000000108887c10 [...long output...]>
is expected to have html body to #<RSpec::Matchers::BuiltIn::Match:0x000000010f476228 [...long output...]>
is expected to have html body to #<Capybara::RSpecMatchers::Matchers::HaveText:0x0000000140b35fd8 [...long output...]>

Expected behavior
It should generate a readable description :
is expected to have html body to include "Hello World"
is expected to have html body to match /hello/
is expected to have html body to have visible css "#test" with text "Hello World"

Your environment

Ruby 3.2.2
rspec 3.12.0
rspec-expectations 3.12.3
rspec-support 3.12.1

config.include_chain_clauses_in_custom_matcher_descriptions is already set to true
Investigation
There are 3 methods involved to generate chained description :

RSpec::Matchers::DSL#chained_method_clause_sentences
RSpec::Matchers::EnglishPhrasing#list
RSpec::Support::ObjectFormatter.format

I'm not sure which one is the most relevant to fix the issue but my guess is EnglishPhrasing.
Something like :
   def self.list(obj)
     return " #{RSpec::Support::ObjectFormatter.format(obj)}" if !obj || Struct === obj || Hash === obj
-    items = Array(obj).map { |w| RSpec::Support::ObjectFormatter.format(w) }
+    items = Array(obj).map { |w| w.is_a?(RSpec::Matchers::Composable) ? w.description : RSpec::Support::ObjectFormatter.format(w) }

This is not how you chain matchers.
There’s the and/or mechanism built-in http://rspec.info/features/3-12/rspec-expectations/compound-expectations/

Thanks, but I dont want to chain matcher with the same subject.
Matchers chained to have_html_body.to receive a transformed subject.

Your example is not indicative of that: you pass @actual to the other matcher.
I understand what you are trying to work around. This will be solved in this pr https://github.com/rspec/rspec-expectations/pull/1319, but it’s a breaking change, so only in RSpec 4.

Sounds nice but it seems to me that the PR you've linked will only change the output diff on test failures. Am I wrong ?
Maybe this is part of larger changes for RSpec 4 ?
In the matcher above, I have no problem to output a good failure message of chained matchers ... except for the description part.
matcher :have_html_body do
  chain :to,     :other_matcher
  chain :not_to, :other_negative_matcher

  failure_message do
    message  = "expected to #{description}"
    message += "\n#{other_matcher&.failure_message}" if other_matcher
    message += "\n#{other_negative_matcher&.failure_message_when_negated}" if other_negative_matcher
    message
  end
end

Do you have any issue with printed example descriptions of chained matchers built using the built-in compound mechanism?


Being able to do A/B testing - Canary

When using an orchestrator (like Marathon), we often want to "bulletproof" software releases by deploying a new version on a small set of instances.
Current workaround it to set traefik.backend to the same value in A and B versions.
It works but it avoids being able to create frontend that targets a specific version.
What is possible:

Frontend with multiple backends

Virtual Backends (who only redirect to other backends)

Backends with nested backend

What are you thinking about this?

Actually, I'm not sure but I'm thinking about that issue as well :) I feel like option 1 is my favorite but I'm really not sure.

Solution 1 is really attractive because it's the most logical, but it has many problems.
Most important is the duplication of configuration between frontend and backend (wrr, ...).
After more reflection I think solution 3 respond to every solution without more configuration. A backend will only work like any other server and it's possible to do the same than 2 with 3.

Is it possible to document this pattern? I wonder how it can work and what needs to be done on Marathon to do it? Apparently, Kubernetes does it already.

@Stibbons curious, how does Kubernetes does this?
The one approach I'm aware of is to spawn more Pods and adjust service labels accordingly, which all seems to be below the proxy/Ingress level that Traefik operates on.

Sorry, I should not have said "Kuberentes does it already". I correct it in my statement. Should be like: Kubernetes allow Rolling update with time delay/period (--update-period argument or kubectl rollingupdate). This is not strictly a controlled A/B testing deployment. To my understanding, Marathon does not provide it, and probably the K8s' Replication Controler is easier to drive to perform a A/B deployment than Marathon API.
In anyway, if Traefik can document inside the official doc how to configure both K8s and Marathon to have an A/B deployment with Traefik, this would be simply extraordinaire!

I also really have a need for this. Right now I have multiple swarm services (A/B) both declaring the same frontend Host label, attempting to do this kind of thing, but it doesn't work, only the first frontend declared w/ a Host label gets the traffic.

@guilhem in your diagram above when you say "what is possible". Are any of those in your diagram currently possible? For example "frontend with multiple backends"... i don't think this is currently possible correct?

@bitsofinfo correct, those are proposals, they are not currently supported. I validated the same thing in the slack channel the other day. :) I also tried the suggestion of overriding the traefik.backend to have both stacks use the same backend but Rancher backend doesn't support it. So I'm watching for updates here.

So if want to accomplish this today....  if I have 2 separate docker services (A/B), if they both share the same -traefik.frontend.rule=Host:myhosts.test.com -traefik.backend=backend-one, this will create ONE frontend (or two frontends?), sharing the same Host:myhosts.test.com binding but only **one** of them will actually take the requests... but since it goes to this shared backend (backend-one`) replicas from BOTH A/B docker services exist in it...effectively giving me psuedo 50% A and 50% B containers servicing the request.... correct?

@bitsofinfo I'm not on the Traefik team but AFAIK, neither of those configs are supported. It MAY work as indicated by @guilhem since the marathon backend seems to work but your milage may vary. So to clarify, today there are no officially supported or functional canary - A/B config scenarios. Anyone else feel free to correct me if I've misspoken.

 One of the front-ends seems useless I guess. Would definitely be nice to just have Host matches ACROSS front-ends, round-robin appropriately to the different backends, without having to do the traefik.backend=[name] thing

The other scenario is if you want to have an Host that serves up a mixed A/B backend, but still have a way to access the B version separately, unfortunately you have to do it like the below, and can't just point to the existing nginx-2-0 service:
Launch 3 nginx services
docker service create --name nginx-1-0 --network omg-app-dev-int \
--mount type=bind,source=/tmp/nginx-1-0.html,target=/usr/share/nginx/html/index.html \
--label traefik.enable=true \
--label traefik.protocol=http \
--label traefik.port=80 \
--label traefik.frontend.rule=Host:nginx-current.mydomain.com \
--label traefik.docker.network=omg-app-dev-int \
--label traefik.backend=nginx-prod \
nginx

docker service create --name nginx-2-0 --network omg-app-dev-int \
--mount type=bind,source=/tmp/nginx-2-0.html,target=/usr/share/nginx/html/index.html \
--label traefik.enable=true \
--label traefik.protocol=http \
--label traefik.port=80 \
--label traefik.frontend.rule=Host:nginx-current.mydomain.com \
--label traefik.docker.network=omg-app-dev-int \
--label traefik.backend=nginx-prod \
nginx

docker service create --name nginx-2-0-nv --network omg-app-dev-int \
--mount type=bind,source=/tmp/nginx-2-0.html,target=/usr/share/nginx/html/index.html \
--label traefik.enable=true \
--label traefik.protocol=http \
--label traefik.port=80 \
--label traefik.frontend.rule=Host:nginx-nv.mydomain.com \
--label traefik.docker.network=omg-app-dev-int \
--label traefik.backend=nginx-prod-nv \
nginx

Traefik dashboard results in:

So here http calls to nginx-current.mydomain.com result in 50/50 to both 1-0/2-0, but to hit 2-0 specifically via nginx-nv.mydomain.com it needs to hit a second service instance which is essentially just a "re-deployment" with a different service name (nginx-2-0-nv), to get traefik to let us hit it specifically (rather than just have a 2nd host specified when deploying the nginx-2-0 instance and let it be shared across 2 front-ends.

Yes. We currently have this same situation as well where we want to distribute load between two backend service in round robin or random fashion. We would love to see this implemented in the next release. Cheers!

Yes! It would be nice if traefik would just add support for this. The workaround mentioned by @bitsofinfo works but it just adds a lot more complexity and limitations to a service deployment specifically whenever you have to re-deploy a second version of the service just to create a frontend to target that specific version.

I currently have a need for this as well!  A straightforward way to split traffic 50/50 between current version and "new" version of a service would be amazing.

Does this workaround @bitsofinfo works with sticky session? as if you fire a HTTP request, and traefik picks backend A or B at 50%/50%, and the subsequent request from the same user strictly goes to the EXACTLY same backend it hit at first entry?

@milewski I don't know, you'll have to test that: https://docs.traefik.io/basics/#sticky-sessions

Close by #5237


HttpClient cannot use 'USE' query

why and how to resolve it at below photo?

HTTP by default is stateless, to remeber states between different requests you need to use session.

Similarly, you can use ClickHouse sessions in the HTTP protocol. To do this, you need to add the session_id GET parameter to the request. You can use any string as the session ID. By default, the session is terminated after 60 seconds of inactivity. To change this timeout, modify the default_session_timeout setting in the server configuration, or add the session_timeout GET parameter to the request. To check the session status, use the session_check=1 parameter. Only one query at a time can be executed within a single session.

(From https://clickhouse.yandex/docs/en/interfaces/http/ ).
As an alternative you can just pass needed database into database GET parameter. Just like that:
GET 'http://localhost:8123/?database=monitor'

@filimonov thanks


vim very unresponsive

Hi, I need help fixing vim, it seems to be very unresponsive. Each time I want to enter a character or do something I need to hold the key for a couple of seconds (e.g. to just enter a letter, 'p', I need to p key for a few seconds).
The vim editor only behaves like this in Jshell (/edit) but works fine in msys when creating the HelloWorld.java file.
Any help is appreciated. Thanks!!

The fix is to remove vim as the jshell editor.  Use the default one provided.


Teleporting Halfway into the ground?

I've gone through the setup steps numerous times, I've tried moving my floor up and down as well, and everything seems to be working like normal, except the ground is always about chest-high after I teleport once, and I remain at that height after subsequent teleports. I'll note that the indicator circle where you're supposed to end up is displayed at the correct height. The parabola, though, falls through to a lower point.
At first I thought it might be because I scaled my Main Rig object up to twice its original size, but after scaling it back to default the issue remains.
I've been able to "fix" it by changing this line in the TeleportVive script:
offset.y = 0;
I simply changed the value to .75f;
This still leaves the parabola pointing lower than my actual floor, but everything else works as I'd like to. I'm just wondering at this point if its an issue with my own setup or something else.
EDIT: I've realized this is probably intended functionality. I was under the impression your script would land the whole rig on top of whatever ground you used for the navMesh. Rather than requiring users to position their world around this script, perhaps you can add another optional variable for where the ground position is?

Hmm, this seems like a bug of course.  I'll take a look.

Just took a look, the height parameters are working as expected.  I just noticed your edit - you are correct, the system only supports one height at this time, for optimization reasons (perhaps I can relook at this when #9 is addressed).  Supporting multiple heights means polling the navmesh around 15 times per frame (one for each point on the parabolic pointer) and right now that just can't happen.

...perhaps you can add another optional variable for where the ground position is?

This exists, see "Ground Height" in the Parabolic Pointer component.

Hello, an update on this issue.  As of version 2.0.0 the system now supports multiple ground levels.
Get it here:
https://github.com/Flafla2/Vive-Teleporter/releases/tag/v2.0.0


[e2e]: container-based schedule main registry-username-secret

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/7705700123
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.registry-username-secret.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.registry-username-secret.yml
Trigger: schedule
Branch: main
Date: Tue Jan 30 03:06:39 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/7720616073
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.registry-username-secret.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.registry-username-secret.yml
Trigger: schedule
Branch: main
Date: Wed Jan 31 03:06:41 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/7735652930
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.registry-username-secret.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.registry-username-secret.yml
Trigger: schedule
Branch: main
Date: Thu Feb  1 03:11:32 UTC 2024
Tests are passing now. Closing this issue.


Infinite rendering occurs when date or datetime type values are used as arguments.

Describe the bug

To Reproduce
Steps to reproduce the behavior:

My GraphQL schema:

# Put your schema here
type Query {
  test(customArg: String): String
}

My GraphQL operations:

# Put your operations herequery Test($customArg: String!) {
  test(customArg: $customArg)
}

My codegen.yml config file:

# Put your YML here
schema: http://localhost:4000/graphql/
documents: src/graphql/operations/**/*.graphql
generates:
  src/graphql/schemas/generated/schema.ts:
    plugins:
    - typescript
    - typescript-operations
    - typescript-react-apollo
config:
  namingConvention:
    transformUnderscore: true
  scalars:
    BigInt: bigint
    DateTime: string
    EmailAddress: string

Expected behavior

Environment:

OS: MacOS 12.1
@graphql-codegen/...:

    "@graphql-codegen/cli": "^2.6.1",
    "@graphql-codegen/typescript": "^2.4.3",
    "@graphql-codegen/typescript-operations": "^2.3.0",
    "@graphql-codegen/typescript-react-apollo": "^3.2.5",

NodeJS: 16.11.1

Additional context

If you pass dayjs().toISOString() or new Date().toString(), infinite rendering will occur.
With dayjs().toString(), it was not infinite rendering, but it was extra rendering.
I don't know if it's a bug in graphql-code-generator or in GraphQL.js, but I'm sorry if this is the wrong place to post this.
Is there anything I can do to help?

Hi @mayone-du,
Thank you for your report!
Could you please provide a reproduction on Codesandbox by using our template?
➡ https://codesandbox.io/s/github/dotansimha/graphql-code-generator-issue-sandbox-template/tree/master/
Thank you!

@charlypoly
OK, please wait👍


Updated copy of titles & few minor copy fixes

to test: verify the copy on heroku.

You also wanted to update the page description, it should be also updated in translation files. seo section


Instance type are not registered as references

In a code such as
foo u_bar (...);

The definition of foo is correctly found, but the references of the base module are not.
It may be due to the fact that the definition seems to span on the whole module instead of just the name token

Done at some point...


[WiP] Proof of concept e2e testing

I added Behat to our test suite. I made an example test for the listVirtualMachines command.
The FeatureContext file adds the Behat definitions that are used in the *.feature files.
Merging this PR would fix #23

Coverage remained the same at 48.736% when pulling 5f7b2f7f3e8a14977d43f69ae07b8c9eb5853aff on FrontEndCoffee:e2e into 9e38cd57221184ab598113214899cf64a9928d92 on PCextreme:master.

Coverage remained the same at 48.736% when pulling 674c205844cdd87ea970a7d45eecc3348ceb4ab6 on FrontEndCoffee:e2e into 9e38cd57221184ab598113214899cf64a9928d92 on PCextreme:master.

Coverage remained the same at 48.736% when pulling 5f7b2f7f3e8a14977d43f69ae07b8c9eb5853aff on FrontEndCoffee:e2e into 9e38cd57221184ab598113214899cf64a9928d92 on PCextreme:master.

Coverage remained the same at 48.736% when pulling 674c205844cdd87ea970a7d45eecc3348ceb4ab6 on FrontEndCoffee:e2e into 9e38cd57221184ab598113214899cf64a9928d92 on PCextreme:master.

As discussed internally, we won't add E2E tests to this package at the moment.


nixos/rabbitmq: prefer 'install' over 'mkdir/chmod/chown'

Description of changes
part of #121293
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

cc @turion - rabbitmq package maintainer.
I've renamed the cookie option to unsafeCookie, without deprecation cycle because nobody should be using this option in a production environment anyway.

Thanks!


How can I get the proposals' level0 feature without ROI_Align or ROI_pooling?

I want to get the original feature map of a proposal, I found the ROI_head code and mmcv/ops/roi_align.py, but I can't tell where is the original feature map of a proposal. Could you tell me where it is?

https://github.com/open-mmlab/mmdetection/blob/ca11860f4f3c3ca2ce8340e2686eeaec05b29111/mmdet/models/roi_heads/standard_roi_head.py#L121

Thank you， I should explain it more in detail，I want to get the feature map without ROI_align. https://github.com/open-mmlab/mmcv/blob/master/mmcv/ops/roi_align.py#L93 . It goes with Align,I don't want Align, I want the original feature of proposals.

You can rewrite  self.bbox_roi_extractor, x is the feats, and rois is available.
Referring to https://github.com/open-mmlab/mmcv/blob/0230fc3bc09d160fde228cea35609c8e327d6978/mmcv/ops/roi_align.py#L65


envoy: use local_resources parameter during bazel build

This sets the resources for memory, CPU, and I/O for the bazel build.
This avoids errors like the following when building Envoy:
23:27:39     virtualbox-iso: ERROR: /home/vagrant/.cache/bazel/_bazel_vagrant/502ef5068e38073dd9828a920a71f484/external/envoy/source/server/http/BUILD:11:1: C++ compilation of rule '@envoy//source/server/http:admin_lib' failed (Exit 4)
23:27:39     virtualbox-iso: gcc: internal compiler error: Killed (program cc1plus)
23:27:39     virtualbox-iso: Please submit a full bug report,
23:27:39     virtualbox-iso: with preprocessed source if appropriate.
23:27:39     virtualbox-iso: See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
23:27:39     virtualbox-iso: Target //:envoy failed to build
23:27:39     virtualbox-iso: Use --verbose_failures to see the command lines of failed build steps.
23:27:39     virtualbox-iso: INFO: Elapsed time: 444.469s, Critical Path: 74.62s
23:27:39     virtualbox-iso: INFO: 1544 processes, local.
23:27:39     virtualbox-iso: FAILED: Build did NOT complete successfully
23:27:39     virtualbox-iso: FAILED: Build did NOT complete successfully
23:27:40     virtualbox-iso: make: *** [envoy-release] Error 1
23:27:40     virtualbox-iso: Makefile:68: recipe for target 'envoy-release' failed
23:27:41 ==> virtualbox-iso: Deregistering and deleting VM...
23:27:41 ==> virtualbox-iso: Deleting output directory...
23:27:41 Build 'virtualbox-iso' errored: Script exited with non-zero exit status: 2

Signed-off by: Ian Vernon<EMAIL_ADDRESS>Fixes: #4740

This change is

Until this is merged, #2688 is blocked.

This needs backport to v1.0 and v1.1, otherwise we can't build VMs against v1.0 and v1.1. with Ubuntu 18.04 LTS support. I got the following error when building against v1.0:
22:04:59     virtualbox-iso: [1,850 / 1,900] Compiling external/envoy/source/common/router/config_impl.cc; 33s local ... (8 actions running)
22:05:01     virtualbox-iso: ERROR: /home/vagrant/.cache/bazel/_bazel_vagrant/502ef5068e38073dd9828a920a71f484/external/envoy/source/common/router/BUILD:11:1: C++ compilation of rule '@envoy//source/common/router:config_lib' failed (Exit 4)
22:05:01     virtualbox-iso: gcc: internal compiler error: Killed (program cc1plus)
22:05:01     virtualbox-iso: Please submit a full bug report,
22:05:01     virtualbox-iso: with preprocessed source if appropriate.
22:05:01     virtualbox-iso: See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
22:05:07     virtualbox-iso: Target //:envoy failed to build
22:05:07     virtualbox-iso: Use --verbose_failures to see the command lines of failed build steps.
22:05:07     virtualbox-iso: INFO: Elapsed time: 376.577s, Critical Path: 46.88s
22:05:07     virtualbox-iso: FAILED: Build did NOT complete successfully
22:05:07     virtualbox-iso: make: *** [envoy-release] Error 1
22:05:07     virtualbox-iso: Makefile:61: recipe for target 'envoy-release' failed
22:05:08 ==> virtualbox-iso: Deregistering and deleting VM...
22:05:08 ==> virtualbox-iso: Deleting output directory...
22:05:08 Build 'virtualbox-iso' errored: Script exited with non-zero exit status: 2
22:05:08