[jira] [Comment Edited] (EXEC-120) Some flaky tests
[
https://issues.apache.org/jira/browse/EXEC-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722296#comment-17722296
]
Gary D. Gregory edited comment on EXEC-120 at 5/12/23 9:40 PM:
---
[~agorguy] The test cases in question pass consistently for me locally with
{{mvn clean test}}. They also consistently pass on GitHub [1]. Unless you can
tell me what you think is specifically wrong with those test cases and how they
should be fixed or improved I see little value in adding anything to the
project README concerning those tests. In any case, the README for the Commons
components is generated at release time, so a Javadoc comment would only make
sense anyway, this would not be information for the README.
[1] https://github.com/apache/commons-exec/actions
was (Author: garydgregory):
Sigh
> Some flaky tests
>
>
> Key: EXEC-120
> URL: https://issues.apache.org/jira/browse/EXEC-120
> Project: Commons Exec
> Issue Type: Bug
>Reporter: Agor
>Priority: Major
>
> Hello,
> We tried running this project and discovered that it contains some flaky
> tests (i.e., tests that nondeterministically pass and fail). We found these
> tests to fail more frequently when running them on certain machines of ours.
> To prevent others from running this project and its tests in machines that
> may result in flaky tests, we suggest adding information to the README.md
> file indicating the minimum resource configuration for running the tests of
> this project as to prevent observation of test flakiness.
> If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
> tests. We found that the tests in this project did not have any flaky tests
> when we ran it on machines with 2cpu and 2gb ram.
> Here is a list of the tests we have identified and their likelihood of
> failure on a system with less than the recommended 2 CPUs and 2 GB RAM.
> # org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
> #
> org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
> (2 out 10)
> Please let me know if you would like us to create a pull request on this
> matter (possibly to the readme of this project).
> Thank you for your attention to this matter. We hope that our recommendations
> will be helpful in improving the quality and performance of your project,
> especially for others to use.
> Reproducing
> {code:java}
> FROM maven:3.5.4-jdk-11
> WORKDIR /home/
> RUN git clone https://github.com/apache/commons-exec && \
> cd commons-exec && \
> git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
> WORKDIR /home/commons-exec
> RUN mvn install -DskipTests
> ENTRYPOINT ["mvn", "test", "-fn"]
> {code}
> Build the image:
> {code:java}
> $> mkdir tmp
> $> cp Dockerfile tmp
> $> cd tmp
> $> docker build -t commons-exec . # estimated time of build 3m
> {code}
>
> Running:
> this configuration likely prevents flakiness (no flakiness in 10 runs)
> {code:java}
> $> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
> output.txt
> $> grep "Failures:" output.txt # checking results{code}
> this other configuration –similar to the previous– can’t prevent flaky tests
> (observation in 10 runs)
> {code:java}
> $> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
> output2.txt
> $> grep "Failures:" output2.txt # checking results{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (EXEC-120) Some flaky tests
[
https://issues.apache.org/jira/browse/EXEC-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722296#comment-17722296
]
Gary D. Gregory commented on EXEC-120:
--
Sigh
> Some flaky tests
>
>
> Key: EXEC-120
> URL: https://issues.apache.org/jira/browse/EXEC-120
> Project: Commons Exec
> Issue Type: Bug
>Reporter: Agor
>Priority: Major
>
> Hello,
> We tried running this project and discovered that it contains some flaky
> tests (i.e., tests that nondeterministically pass and fail). We found these
> tests to fail more frequently when running them on certain machines of ours.
> To prevent others from running this project and its tests in machines that
> may result in flaky tests, we suggest adding information to the README.md
> file indicating the minimum resource configuration for running the tests of
> this project as to prevent observation of test flakiness.
> If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
> tests. We found that the tests in this project did not have any flaky tests
> when we ran it on machines with 2cpu and 2gb ram.
> Here is a list of the tests we have identified and their likelihood of
> failure on a system with less than the recommended 2 CPUs and 2 GB RAM.
> # org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
> #
> org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
> (2 out 10)
> Please let me know if you would like us to create a pull request on this
> matter (possibly to the readme of this project).
> Thank you for your attention to this matter. We hope that our recommendations
> will be helpful in improving the quality and performance of your project,
> especially for others to use.
> Reproducing
> {code:java}
> FROM maven:3.5.4-jdk-11
> WORKDIR /home/
> RUN git clone https://github.com/apache/commons-exec && \
> cd commons-exec && \
> git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
> WORKDIR /home/commons-exec
> RUN mvn install -DskipTests
> ENTRYPOINT ["mvn", "test", "-fn"]
> {code}
> Build the image:
> {code:java}
> $> mkdir tmp
> $> cp Dockerfile tmp
> $> cd tmp
> $> docker build -t commons-exec . # estimated time of build 3m
> {code}
>
> Running:
> this configuration likely prevents flakiness (no flakiness in 10 runs)
> {code:java}
> $> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
> output.txt
> $> grep "Failures:" output.txt # checking results{code}
> this other configuration –similar to the previous– can’t prevent flaky tests
> (observation in 10 runs)
> {code:java}
> $> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
> output2.txt
> $> grep "Failures:" output2.txt # checking results{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-configuration] garydgregory commented on pull request #300: Take prefix delimiter into account when SubsetConfiguration.getKeysInternal() is called
garydgregory commented on PR #300: URL: https://github.com/apache/commons-configuration/pull/300#issuecomment-1546210630 > Please excuse the amount of commits :/ You can squash them if you want. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] KeijoB commented on pull request #300: Take prefix delimiter into account when SubsetConfiguration.getKeysInternal() is called
KeijoB commented on PR #300: URL: https://github.com/apache/commons-configuration/pull/300#issuecomment-1546201485 Please excuse the amount of commits :/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (EXEC-120) Some flaky tests
[
https://issues.apache.org/jira/browse/EXEC-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Agor updated EXEC-120:
--
Description:
Hello,
We tried running your project and discovered that it contains some flaky tests
(i.e., tests that nondeterministically pass and fail). We found these tests to
fail more frequently when running them on certain machines of ours.
To prevent others from running this project and its tests in machines that may
result in flaky tests, we suggest adding information to the README.md file
indicating the minimum resource configuration for running the tests of this
project as to prevent observation of test flakiness.
If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
tests. We found that the tests in this project did not have any flaky tests
when we ran it on machines with 2cpu and 2gb ram.
Here is a list of the tests we have identified and their likelihood of failure
on a system with less than the recommended 2 CPUs and 2 GB RAM.
# org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
# org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
(2 out 10)
Please let me know if you would like us to create a pull request on this matter
(possibly to the readme of this project).
Thank you for your attention to this matter. We hope that our recommendations
will be helpful in improving the quality and performance of your project,
especially for others to use.
Reproducing
{code:java}
FROM maven:3.5.4-jdk-11
WORKDIR /home/
RUN git clone https://github.com/apache/commons-exec && \
cd commons-exec && \
git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
WORKDIR /home/commons-exec
RUN mvn install -DskipTests
ENTRYPOINT ["mvn", "test", "-fn"]
{code}
Build the image:
{code:java}
$> mkdir tmp
$> cp Dockerfile tmp
$> cd tmp
$> docker build -t commons-exec . # estimated time of build 3m
{code}
Running:
this configuration likely prevents flakiness (no flakiness in 10 runs)
{code:java}
$> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
output.txt
$> grep "Failures:" output.txt # checking results{code}
this other configuration –similar to the previous– can’t prevent flaky tests
(observation in 10 runs)
{code:java}
$> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
output2.txt
$> grep "Failures:" output2.txt # checking results{code}
was:
Hello,
We tried running your project and discovered that it contains some flaky tests
(i.e., tests that nondeterministically pass and fail). We found these tests to
fail more frequently when running them on certain machines of ours.
To prevent others from running this project and its tests in machines that may
result in flaky tests, we suggest adding information to the README.md file
indicating the minimum resource configuration for running the tests of this
project as to prevent observation of test flakiness.
If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
tests. We found that the tests in this project did not have any flaky tests
when we ran it on machines with 2cpu and 2gb ram.
Here is a list of the tests we have identified and their likelihood of failure
on a system with less than the recommended 2 CPUs and 2 GB RAM.
# org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
# org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
(2 out 10)
Please let me know if you would like us to create a pull request on this matter
(possibly to the readme of this project).
Thank you for your attention to this matter. We hope that our recommendations
will be helpful in improving the quality and performance of your project,
especially for others to use.
Reproducing
{code:java}
FROM maven:3.5.4-jdk-11
WORKDIR /home/
RUN git clone https://github.com/apache/commons-exec && \
cd commons-exec && \
git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
WORKDIR /home/commons-exec
RUN mvn install -DskipTests
ENTRYPOINT ["mvn", "test", "-fn"]
{code}
Build the image:
{code:java}
$> mkdir tmp
$> cp Dockerfile tmp
$> cd tmp
$> docker build -t commons-exec . # estimated time of build 3m
{code}
Running:
this configuration likely prevents flakiness (no flakiness in 10 runs)
{code:java}
$> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
output.txt
$> grep "Failures:" output.txt # checking results{code}
this other configuration –similar to the previous– can’t prevent flaky tests
(observation in 10 runs)
{code:java}
$> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
output2.txt
$> grep "Failures:" output2.txt # checking results{code}
> Some flaky tests
>
>
> Key: EXEC-120
> URL: https://issues.apache.org/jira/browse/EXEC-120
> Project: Commons Exec
> Issue Type: Bug
>Reporter:
[jira] [Updated] (EXEC-120) Some flaky tests
[
https://issues.apache.org/jira/browse/EXEC-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Agor updated EXEC-120:
--
Description:
Hello,
We tried running this project and discovered that it contains some flaky tests
(i.e., tests that nondeterministically pass and fail). We found these tests to
fail more frequently when running them on certain machines of ours.
To prevent others from running this project and its tests in machines that may
result in flaky tests, we suggest adding information to the README.md file
indicating the minimum resource configuration for running the tests of this
project as to prevent observation of test flakiness.
If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
tests. We found that the tests in this project did not have any flaky tests
when we ran it on machines with 2cpu and 2gb ram.
Here is a list of the tests we have identified and their likelihood of failure
on a system with less than the recommended 2 CPUs and 2 GB RAM.
# org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
# org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
(2 out 10)
Please let me know if you would like us to create a pull request on this matter
(possibly to the readme of this project).
Thank you for your attention to this matter. We hope that our recommendations
will be helpful in improving the quality and performance of your project,
especially for others to use.
Reproducing
{code:java}
FROM maven:3.5.4-jdk-11
WORKDIR /home/
RUN git clone https://github.com/apache/commons-exec && \
cd commons-exec && \
git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
WORKDIR /home/commons-exec
RUN mvn install -DskipTests
ENTRYPOINT ["mvn", "test", "-fn"]
{code}
Build the image:
{code:java}
$> mkdir tmp
$> cp Dockerfile tmp
$> cd tmp
$> docker build -t commons-exec . # estimated time of build 3m
{code}
Running:
this configuration likely prevents flakiness (no flakiness in 10 runs)
{code:java}
$> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
output.txt
$> grep "Failures:" output.txt # checking results{code}
this other configuration –similar to the previous– can’t prevent flaky tests
(observation in 10 runs)
{code:java}
$> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
output2.txt
$> grep "Failures:" output2.txt # checking results{code}
was:
Hello,
We tried running your project and discovered that it contains some flaky tests
(i.e., tests that nondeterministically pass and fail). We found these tests to
fail more frequently when running them on certain machines of ours.
To prevent others from running this project and its tests in machines that may
result in flaky tests, we suggest adding information to the README.md file
indicating the minimum resource configuration for running the tests of this
project as to prevent observation of test flakiness.
If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
tests. We found that the tests in this project did not have any flaky tests
when we ran it on machines with 2cpu and 2gb ram.
Here is a list of the tests we have identified and their likelihood of failure
on a system with less than the recommended 2 CPUs and 2 GB RAM.
# org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
# org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
(2 out 10)
Please let me know if you would like us to create a pull request on this matter
(possibly to the readme of this project).
Thank you for your attention to this matter. We hope that our recommendations
will be helpful in improving the quality and performance of your project,
especially for others to use.
Reproducing
{code:java}
FROM maven:3.5.4-jdk-11
WORKDIR /home/
RUN git clone https://github.com/apache/commons-exec && \
cd commons-exec && \
git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
WORKDIR /home/commons-exec
RUN mvn install -DskipTests
ENTRYPOINT ["mvn", "test", "-fn"]
{code}
Build the image:
{code:java}
$> mkdir tmp
$> cp Dockerfile tmp
$> cd tmp
$> docker build -t commons-exec . # estimated time of build 3m
{code}
Running:
this configuration likely prevents flakiness (no flakiness in 10 runs)
{code:java}
$> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
output.txt
$> grep "Failures:" output.txt # checking results{code}
this other configuration –similar to the previous– can’t prevent flaky tests
(observation in 10 runs)
{code:java}
$> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
output2.txt
$> grep "Failures:" output2.txt # checking results{code}
> Some flaky tests
>
>
> Key: EXEC-120
> URL: https://issues.apache.org/jira/browse/EXEC-120
> Project: Commons Exec
> Issue Type: Bug
>Repo
[jira] [Created] (EXEC-120) Some flaky tests
Agor created EXEC-120:
-
Summary: Some flaky tests
Key: EXEC-120
URL: https://issues.apache.org/jira/browse/EXEC-120
Project: Commons Exec
Issue Type: Bug
Reporter: Agor
Hello,
We tried running your project and discovered that it contains some flaky tests
(i.e., tests that nondeterministically pass and fail). We found these tests to
fail more frequently when running them on certain machines of ours.
To prevent others from running this project and its tests in machines that may
result in flaky tests, we suggest adding information to the README.md file
indicating the minimum resource configuration for running the tests of this
project as to prevent observation of test flakiness.
If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
tests. We found that the tests in this project did not have any flaky tests
when we ran it on machines with 2cpu and 2gb ram.
Here is a list of the tests we have identified and their likelihood of failure
on a system with less than the recommended 2 CPUs and 2 GB RAM.
# org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
# org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
(2 out 10)
Please let me know if you would like us to create a pull request on this matter
(possibly to the readme of this project).
Thank you for your attention to this matter. We hope that our recommendations
will be helpful in improving the quality and performance of your project,
especially for others to use.
Reproducing
{code:java}
FROM maven:3.5.4-jdk-11
WORKDIR /home/
RUN git clone https://github.com/apache/commons-exec && \
cd commons-exec && \
git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
WORKDIR /home/commons-exec
RUN mvn install -DskipTests
ENTRYPOINT ["mvn", "test", "-fn"]
{code}
Build the image:
{code:java}
$> mkdir tmp
$> cp Dockerfile tmp
$> cd tmp
$> docker build -t commons-exec . # estimated time of build 3m
{code}
Running:
this configuration likely prevents flakiness (no flakiness in 10 runs)
{code:java}
$> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
output.txt
$> grep "Failures:" output.txt # checking results{code}
this other configuration –similar to the previous– can’t prevent flaky tests
(observation in 10 runs)
{code:java}
$> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
output2.txt
$> grep "Failures:" output2.txt # checking results{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (EXEC-120) Some flaky tests
[
https://issues.apache.org/jira/browse/EXEC-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Agor updated EXEC-120:
--
Description:
Hello,
We tried running your project and discovered that it contains some flaky tests
(i.e., tests that nondeterministically pass and fail). We found these tests to
fail more frequently when running them on certain machines of ours.
To prevent others from running this project and its tests in machines that may
result in flaky tests, we suggest adding information to the README.md file
indicating the minimum resource configuration for running the tests of this
project as to prevent observation of test flakiness.
If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
tests. We found that the tests in this project did not have any flaky tests
when we ran it on machines with 2cpu and 2gb ram.
Here is a list of the tests we have identified and their likelihood of failure
on a system with less than the recommended 2 CPUs and 2 GB RAM.
# org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
# org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
(2 out 10)
Please let me know if you would like us to create a pull request on this matter
(possibly to the readme of this project).
Thank you for your attention to this matter. We hope that our recommendations
will be helpful in improving the quality and performance of your project,
especially for others to use.
Reproducing
{code:java}
FROM maven:3.5.4-jdk-11
WORKDIR /home/
RUN git clone https://github.com/apache/commons-exec && \
cd commons-exec && \
git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
WORKDIR /home/commons-exec
RUN mvn install -DskipTests
ENTRYPOINT ["mvn", "test", "-fn"]
{code}
Build the image:
{code:java}
$> mkdir tmp
$> cp Dockerfile tmp
$> cd tmp
$> docker build -t commons-exec . # estimated time of build 3m
{code}
Running:
this configuration likely prevents flakiness (no flakiness in 10 runs)
{code:java}
$> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
output.txt
$> grep "Failures:" output.txt # checking results{code}
this other configuration –similar to the previous– can’t prevent flaky tests
(observation in 10 runs)
{code:java}
$> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
output2.txt
$> grep "Failures:" output2.txt # checking results{code}
was:
Hello,
We tried running your project and discovered that it contains some flaky tests
(i.e., tests that nondeterministically pass and fail). We found these tests to
fail more frequently when running them on certain machines of ours.
To prevent others from running this project and its tests in machines that may
result in flaky tests, we suggest adding information to the README.md file
indicating the minimum resource configuration for running the tests of this
project as to prevent observation of test flakiness.
If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
tests. We found that the tests in this project did not have any flaky tests
when we ran it on machines with 2cpu and 2gb ram.
Here is a list of the tests we have identified and their likelihood of failure
on a system with less than the recommended 2 CPUs and 2 GB RAM.
# org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
# org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
(2 out 10)
Please let me know if you would like us to create a pull request on this matter
(possibly to the readme of this project).
Thank you for your attention to this matter. We hope that our recommendations
will be helpful in improving the quality and performance of your project,
especially for others to use.
Reproducing
{code:java}
FROM maven:3.5.4-jdk-11
WORKDIR /home/
RUN git clone https://github.com/apache/commons-exec && \
cd commons-exec && \
git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
WORKDIR /home/commons-exec
RUN mvn install -DskipTests
ENTRYPOINT ["mvn", "test", "-fn"]
{code}
Build the image:
{code:java}
$> mkdir tmp
$> cp Dockerfile tmp
$> cd tmp
$> docker build -t commons-exec . # estimated time of build 3m
{code}
Running:
this configuration likely prevents flakiness (no flakiness in 10 runs)
{code:java}
$> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
output.txt
$> grep "Failures:" output.txt # checking results{code}
this other configuration –similar to the previous– can’t prevent flaky tests
(observation in 10 runs)
{code:java}
$> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
output2.txt
$> grep "Failures:" output2.txt # checking results{code}
> Some flaky tests
>
>
> Key: EXEC-120
> URL: https://issues.apache.org/jira/browse/EXEC-120
> Project: Commons Exec
> Issue Type: Bug
>Reporter
[jira] [Updated] (EXEC-120) Some flaky tests
[
https://issues.apache.org/jira/browse/EXEC-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Agor updated EXEC-120:
--
Description:
Hello,
We tried running your project and discovered that it contains some flaky tests
(i.e., tests that nondeterministically pass and fail). We found these tests to
fail more frequently when running them on certain machines of ours.
To prevent others from running this project and its tests in machines that may
result in flaky tests, we suggest adding information to the README.md file
indicating the minimum resource configuration for running the tests of this
project as to prevent observation of test flakiness.
If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
tests. We found that the tests in this project did not have any flaky tests
when we ran it on machines with 2cpu and 2gb ram.
Here is a list of the tests we have identified and their likelihood of failure
on a system with less than the recommended 2 CPUs and 2 GB RAM.
# org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
# org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
(2 out 10)
Please let me know if you would like us to create a pull request on this matter
(possibly to the readme of this project).
Thank you for your attention to this matter. We hope that our recommendations
will be helpful in improving the quality and performance of your project,
especially for others to use.
Reproducing
{code:java}
FROM maven:3.5.4-jdk-11
WORKDIR /home/
RUN git clone https://github.com/apache/commons-exec && \
cd commons-exec && \
git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
WORKDIR /home/commons-exec
RUN mvn install -DskipTests
ENTRYPOINT ["mvn", "test", "-fn"]
{code}
Build the image:
{code:java}
$> mkdir tmp
$> cp Dockerfile tmp
$> cd tmp
$> docker build -t commons-exec . # estimated time of build 3m
{code}
Running:
this configuration likely prevents flakiness (no flakiness in 10 runs)
{code:java}
$> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
output.txt
$> grep "Failures:" output.txt # checking results{code}
this other configuration –similar to the previous– can’t prevent flaky tests
(observation in 10 runs)
{code:java}
$> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
output2.txt
$> grep "Failures:" output2.txt # checking results{code}
was:
Hello,
We tried running your project and discovered that it contains some flaky tests
(i.e., tests that nondeterministically pass and fail). We found these tests to
fail more frequently when running them on certain machines of ours.
To prevent others from running this project and its tests in machines that may
result in flaky tests, we suggest adding information to the README.md file
indicating the minimum resource configuration for running the tests of this
project as to prevent observation of test flakiness.
If we run this project in a machine with 1cpu and 1gb ram, we observe flaky
tests. We found that the tests in this project did not have any flaky tests
when we ran it on machines with 2cpu and 2gb ram.
Here is a list of the tests we have identified and their likelihood of failure
on a system with less than the recommended 2 CPUs and 2 GB RAM.
# org.apache.commons.exec.issues.Exec34Test#testExec34_1 (2 out 10)
# org.apache.commons.exec.issues.Exec65Test#testExec65WithSudoUsingShellScript
(2 out 10)
Please let me know if you would like us to create a pull request on this matter
(possibly to the readme of this project).
Thank you for your attention to this matter. We hope that our recommendations
will be helpful in improving the quality and performance of your project,
especially for others to use.
Reproducing
{code:java}
FROM maven:3.5.4-jdk-11
WORKDIR /home/
RUN git clone https://github.com/apache/commons-exec && \
cd commons-exec && \
git checkout 7204a355ba5ffba21d828ce993b27c81b5565f43
WORKDIR /home/commons-exec
RUN mvn install -DskipTests
ENTRYPOINT ["mvn", "test", "-fn"]
{code}
Build the image:
{code:java}
$> mkdir tmp
$> cp Dockerfile tmp
$> cd tmp
$> docker build -t commons-exec . # estimated time of build 3m
{code}
Running:
this configuration likely prevents flakiness (no flakiness in 10 runs)
{code:java}
$> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 commons-exec | tee
output.txt
$> grep "Failures:" output.txt # checking results{code}
this other configuration –similar to the previous– can’t prevent flaky tests
(observation in 10 runs)
{code:java}
$> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 commons-exec | tee
output2.txt
$> grep "Failures:" output2.txt # checking results{code}
> Some flaky tests
>
>
> Key: EXEC-120
> URL: https://issues.apache.org/jira/browse/EXEC-120
> Project: Commons Exec
> Issue Type: Bug
>Reporter: Agor
>
[jira] [Updated] (DAEMON-458) The changes in DAEMON-446 cause existing DependsOn values to be removed
[
https://issues.apache.org/jira/browse/DAEMON-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas updated DAEMON-458:
---
Component/s: Procrun
> The changes in DAEMON-446 cause existing DependsOn values to be removed
> ---
>
> Key: DAEMON-458
> URL: https://issues.apache.org/jira/browse/DAEMON-458
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Brian Andle
>Priority: Major
> Fix For: 1.3.4
>
>
> As part of DAEMON-446 a regression was introduced that causes existing
> service DependsOn services to be removed when working with the //US option.
>
> Replication:
> Run:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=MyService
> --DisplayName=MyService
> sc config MyService depend=Tcpip/Afd/Dhcp {code}
> View the services and note that *MyService* depends on Dhcp (the sc config
> command is being used to represent a separate script call)
> Now run:
> {code:java}
> prunsrv.exe //US/MyService --Startup=manual {code}
> View the services and note that MyService no longer depends on Dhcp
> The offending code appears to be the following in service.c:
> {code:java}
> /* Add the mandatory dependencies */
> if (lpDependencies) {
> lpDependencies = apxMultiSzCombine(NULL, lpDependencies,
> L"Tcpip\0Afd\0", NULL);
> } else {
> lpDependencies = L"Tcpip\0Afd\0";
> }{code}
> Which means if DependsOn isn't defined we'll always pass down Tcpip and Afd,
> vs the NULL that happened before. Wiping existing custom dependancies out.
> I didn't test it but this code may not work properly with the – vs ++ logic
> defined under [https://commons.apache.org/proper/commons-daemon/procrun.html]
> The DAEMON-446 ticket talks about --DependsOn (full replace) although I only
> see ++Depends on documented, so maybe DAEMON-446 was actually invalid to
> begin with?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-parent] garydgregory merged pull request #270: Bump build-helper-maven-plugin from 3.3.0 to 3.4.0
garydgregory merged PR #270: URL: https://github.com/apache/commons-parent/pull/270 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (COMPRESS-644) Don't trust tar detection on zero byte record?
Tim Allison created COMPRESS-644:
Summary: Don't trust tar detection on zero byte record?
Key: COMPRESS-644
URL: https://issues.apache.org/jira/browse/COMPRESS-644
Project: Commons Compress
Issue Type: Improvement
Reporter: Tim Allison
Attachments: ARW05UP.ICO
Over on Tika, this file is being detected as a tar file. It is an os/2 bitmap
array file.
We're using {{ArchiveStreamFactory.detect()}}, which finds no magic so it gets
down to:
{noformat}
tais = new TarArchiveInputStream(new ByteArrayInputStream(tarHeader));
if (tais.getNextTarEntry().isCheckSumOK())
{noformat}
The next tar entry has length 0 and the checksum of 0 works.
If you're up for it, it might make sense to check that the next tar entry has a
length > 0.
I realize that this is a trivial/rare problem with a rare or specially crafted
file. And, I realize that this only fixes one special case. I'm not sure it
makes sense to add complexity to your logic.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-configuration] KeijoB opened a new pull request, #300: Take prefix delimiter into account when SubsetConfiguration.getKeysInternal() is called
KeijoB opened a new pull request, #300:
URL: https://github.com/apache/commons-configuration/pull/300
Currently when initializing a
org.apache.commons.configuration2.SubsetConfiguration.SubsetConfiguration(Configuration,
String, String) with a delimiter (other than ".") methods
SubsetConfiguration.getKeys() and SubsetConfiguration.isEmpty() wont work.
- SubsetConfiguration.isEmpty() always will return "true"
- SubsetConfiguration.getKeys() always will return an empty iterator
This is because SubsetConfiguration.getKeysInternal() instantiates a
SubsetIterator and passing the iterator returned by
org.apache.commons.configuration2.AbstractConfiguration.getKeys(String)
```
@Override
protected Iterator getKeysInternal() {
return new SubsetIterator(parent.getKeys(prefix));
}
```
With org.apache.commons.configuration2.AbstractConfiguration.getKeys(String)
org.apache.commons.configuration2.PrefixedKeysIterator.PrefixedKeysIterator is
instantiated. Here "." is hard coded to be used as a prefix delimiter, as also
mentioned in the Javadoc.
org.apache.commons.configuration2.PrefixedKeysIterator.setNextElement():
```
private boolean setNextElement() {
while (iterator.hasNext()) {
final String key = iterator.next();
if (key.startsWith(prefix + ".") || key.equals(prefix)) {
nextElement = key;
nextElementSet = true;
return true;
}
}
return false;
}
```
When using SubsetConfiguration with a specified delimiter the delimiter
should also be used consequently.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
