: build-dev On Behalf Of Magnus Ihse
Bursie
Sent: Freitag, 3. Juni 2022 01:10
To: Andrey Turbanov ; [email protected]
Subject: Re: Warning about git from 'make test' on Windows
On 2022-06-02 21:26, Andrey Turbanov wrote:
Hello.
I noticed strange warnings produced by 'make
On Tue, 7 Jun 2022 18:15:30 GMT, Leo Korinth wrote:
>> One can select a testcase by ID when running a jtreg test case directly from
>> jtreg (using the testcase.java#testID syntax). However, this has not been
>> possible to do when launching jtreg indirectly from make.
>&g
On Tue, 7 Jun 2022 18:15:30 GMT, Leo Korinth wrote:
>> One can select a testcase by ID when running a jtreg test case directly from
>> jtreg (using the testcase.java#testID syntax). However, this has not been
>> possible to do when launching jtreg indirectly from make.
>&g
(suffix $(notdir $1
>> 356:
>> 357: # The test selector starting with a hash (#testid) will be stripped by
>> all
>
> Small nit - I think "selection" and "test selector" in the comments should be
> changed to "test id" so you don'
> One can select a testcase by ID when running a jtreg test case directly from
> jtreg (using the testcase.java#testID syntax). However, this has not been
> possible to do when launching jtreg indirectly from make.
>
> This fix attempts to address this issue. I have not tested
On Tue, 7 Jun 2022 17:39:14 GMT, Leo Korinth wrote:
>> One can select a testcase by ID when running a jtreg test case directly from
>> jtreg (using the testcase.java#testID syntax). However, this has not been
>> possible to do when launching jtreg indirectly from make.
>&g
On Mon, 6 Jun 2022 16:20:18 GMT, Ioi Lam wrote:
>> Let me ask the obvious "dumb" question ... why does this have to be so
>> complicated? Why isn't the name of the test simply passed through to jtreg
>> as typed?
>
>> Let me ask the obvious "
> One can select a testcase by ID when running a jtreg test case directly from
> jtreg (using the testcase.java#testID syntax). However, this has not been
> possible to do when launching jtreg indirectly from make.
>
> This fix attempts to address this issue. I have not tested
On Tue, 7 Jun 2022 13:45:47 GMT, Leo Korinth wrote:
>> One can select a testcase by ID when running a jtreg test case directly from
>> jtreg (using the testcase.java#testID syntax). However, this has not been
>> possible to do when launching jtreg indirectly from make.
>&g
On Tue, 7 Jun 2022 13:45:47 GMT, Leo Korinth wrote:
>> One can select a testcase by ID when running a jtreg test case directly from
>> jtreg (using the testcase.java#testID syntax). However, this has not been
>> possible to do when launching jtreg indirectly from make.
>&g
On Mon, 6 Jun 2022 07:55:09 GMT, Erik Joelsson wrote:
>> Leo Korinth has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> wip
>
> make/RunTests.gmk line 444:
>
>> 442: $(strip $(foreach parser,ParseCustomTestSelection
>> ParseGtestTestSelec
On Tue, 7 Jun 2022 13:45:47 GMT, Leo Korinth wrote:
>> One can select a testcase by ID when running a jtreg test case directly from
>> jtreg (using the testcase.java#testID syntax). However, this has not been
>> possible to do when launching jtreg indirectly from make.
>&g
> One can select a testcase by ID when running a jtreg test case directly from
> jtreg (using the testcase.java#testID syntax). However, this has not been
> possible to do when launching jtreg indirectly from make.
>
> This fix attempts to address this issue. I have not tested
On Tue, 7 Jun 2022 13:26:52 GMT, Leo Korinth wrote:
>> make/RunTests.gmk line 47:
>>
>>> 45: define IfPrepend
>>> 46: $(if $(strip $1),$(strip $2)$(strip $1),)
>>> 47: endef
>>
>> These two probably fits better in make/common/Utils.gmk.
>>
>> Also please have a look at the [Code Conventions f
x $(notdir $1
>> 51: endef
>
> This macro deserves a comment explaining what it's trying to do.
I added a description and made it a one-liner as well
> make/RunTests.gmk line 53:
>
>> 51: endef
>> 52:
>> 53: define HashTestID
>
> This one t
> One can select a testcase by ID when running a jtreg test case directly from
> jtreg (using the testcase.java#testID syntax). However, this has not been
> possible to do when launching jtreg indirectly from make.
>
> This fix attempts to address this issue. I have not tested
On Sat, 4 Jun 2022 01:51:20 GMT, Leo Korinth wrote:
> One can select a testcase by ID when running a jtreg test case directly from
> jtreg (using the testcase.java#testID syntax). However, this has not been
> possible to do when launching jtreg indirectly from make.
>
> This
On Mon, 6 Jun 2022 12:57:25 GMT, Jaikiran Pai wrote:
>> It is currently both tricky and tedious to figure out what went wrong when a
>> jtreg test fails in GHA.
>>
>> We should utilize the full potential of GitHub Action summaries and error
>> annotations to ma
On Mon, 6 Jun 2022 10:48:05 GMT, David Holmes wrote:
> Let me ask the obvious "dumb" question ... why does this have to be so
> complicated? Why isn't the name of the test simply passed through to jtreg as
> typed?
Is it because `#` is treated as comment by the shell
On Thu, 26 May 2022 12:04:41 GMT, Magnus Ihse Bursie wrote:
> With this PR, the overview of failures are presented on the "Summary" page
> for the action (the top-most line to the left, with the outline house icon).
@magicus, thank you. This is really useful. I didn't even know that this
"Summ
On Sat, 4 Jun 2022 01:51:20 GMT, Leo Korinth wrote:
> One can select a testcase by ID when running a jtreg test case directly from
> jtreg (using the testcase.java#testID syntax). However, this has not been
> possible to do when launching jtreg indirectly from make.
>
> This
On Sat, 4 Jun 2022 01:51:20 GMT, Leo Korinth wrote:
> One can select a testcase by ID when running a jtreg test case directly from
> jtreg (using the testcase.java#testID syntax). However, this has not been
> possible to do when launching jtreg indirectly from make.
>
> This
One can select a testcase by ID when running a jtreg test case directly from
jtreg (using the testcase.java#testID syntax). However, this has not been
possible to do when launching jtreg indirectly from make.
This fix attempts to address this issue. I have not tested this thoroughly yet,
I
?
Cheers
Christoph
> -Original Message-
> From: build-dev On Behalf Of Magnus Ihse
> Bursie
> Sent: Freitag, 3. Juni 2022 01:10
> To: Andrey Turbanov ; [email protected]
> Subject: Re: Warning about git from 'make test' on Windows
>
>
>
On 2022-06-02 21:26, Andrey Turbanov wrote:
Hello.
I noticed strange warnings produced by 'make test' recently on my
Win11 installation. For example:
$ make test TEST="tier1"
Building target 'test' in configuration 'windows-x86_64-server-release'
/usr/b
Hello.
I noticed strange warnings produced by 'make test' recently on my
Win11 installation. For example:
$ make test TEST="tier1"
Building target 'test' in configuration 'windows-x86_64-server-release'
/usr/bin/bash: Files/Git/cmd/git: No such file or di
On Thu, 26 May 2022 12:04:41 GMT, Magnus Ihse Bursie wrote:
> It is currently both tricky and tedious to figure out what went wrong when a
> jtreg test fails in GHA.
>
> We should utilize the full potential of GitHub Action summaries and error
> annotations to make finding fail
On Thu, 26 May 2022 12:04:41 GMT, Magnus Ihse Bursie wrote:
> It is currently both tricky and tedious to figure out what went wrong when a
> jtreg test fails in GHA.
>
> We should utilize the full potential of GitHub Action summaries and error
> annotations to make finding fail
It is currently both tricky and tedious to figure out what went wrong when a
jtreg test fails in GHA.
We should utilize the full potential of GitHub Action summaries and error
annotations to make finding failures easier and more discoverable.
With this PR, the overview of failures are
On Mon, 9 May 2022 18:39:28 GMT, Severin Gehwolf wrote:
> `make test TEST="gtest: `1.10.0`. It expects `suites` to be present in the google test output whereas
> the OpenJDK build infra code expects `cases`. I'm not sure when/if that
> changed, but here is a proposed fix.
&
On Tue, 10 May 2022 08:46:44 GMT, Severin Gehwolf wrote:
>> `make test TEST="gtest:> `1.10.0`. It expects `suites` to be present in the google test output
>> whereas the OpenJDK build infra code expects `cases`. I'm not sure when/if
>> that changed, but here is
On Tue, 10 May 2022 08:42:10 GMT, Severin Gehwolf wrote:
> Apparently gtest 1.8.1 uses `cases`. I've updated the patch to handle both:
> `suites` and `cases`. If somebody could test it with gtest 1.8.1 I'd
> appreciate it.
Verified that it works with 1.8.1, which doe
On Tue, 10 May 2022 08:46:44 GMT, Severin Gehwolf wrote:
>> `make test TEST="gtest:> `1.10.0`. It expects `suites` to be present in the google test output
>> whereas the OpenJDK build infra code expects `cases`. I'm not sure when/if
>> that changed, but here is
On Tue, 10 May 2022 08:46:44 GMT, Severin Gehwolf wrote:
>> `make test TEST="gtest:> `1.10.0`. It expects `suites` to be present in the google test output
>> whereas the OpenJDK build infra code expects `cases`. I'm not sure when/if
>> that changed, but here is
> `make test TEST="gtest: `1.10.0`. It expects `suites` to be present in the google test output whereas
> the OpenJDK build infra code expects `cases`. I'm not sure when/if that
> changed, but here is a proposed fix.
>
> Thoughts?
Severin Gehwolf has updated the pull r
On Mon, 9 May 2022 18:39:28 GMT, Severin Gehwolf wrote:
> `make test TEST="gtest: `1.10.0`. It expects `suites` to be present in the google test output whereas
> the OpenJDK build infra code expects `cases`. I'm not sure when/if that
> changed, but here is a proposed
`make test TEST="gtest:https://git.openjdk.java.net/jdk/pull/8605/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8605&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8286430
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk
can be corrected by doing the
> test check only if testing was not skipped.
>
> Here is a link to such a test run where the check failed although the issue
> was with the cygwin installation:
> https://github.com/GoeLin/jdk11u-dev/runs/5788778433?check_suite_focus=true
This pull
ating and it can be corrected by doing the
>> test check only if testing was not skipped.
>>
>> Here is a link to such a test run where the check failed although the issue
>> was with the cygwin installation:
>> https://github.com/GoeLin/jdk11u-dev/runs/578877
can be corrected by doing the
> test check only if testing was not skipped.
>
> Here is a link to such a test run where the check failed although the issue
> was with the cygwin installation:
> https://github.com/GoeLin/jdk11u-dev/runs/5788778433?check_suite_focu
can be corrected by doing the
> test check only if testing was not skipped.
>
> Here is a link to such a test run where the check failed although the issue
> was with the cygwin installation:
> https://github.com/GoeLin/jdk11u-dev/runs/5788778433?check_suite_focus=true
> T
can be corrected by doing the
> test check only if testing was not skipped.
>
> Here is a link to such a test run where the check failed although the issue
> was with the cygwin installation:
> https://github.com/GoeLin/jdk11u-dev/runs/5788778433?check_suite_focus=true
Thanks, thi
In GitHub Actions the step "Check that all tests executed successfully" will be
marked as failing when the "Run tests" step did not run but some earlier step
already failed. This is irritating and it can be corrected by doing the test
check only if testing was not skipped
Hello,
As Alexey says, this should be working.
The data for generating the test-* targets is cached in
build/linux-x86_64-server-fastdebug/make-support/find-tests.gmk. Can you
check if you have this file and if the contents looks corrupted? Try
removing it and see if it gets generated
On 1/21/22 10:25 AM, Liu, Xin wrote:
make -qp can dump all targets. I can't find test-tier1, test-jdk_lang etc.
Huh?
$ make -qp 2>&1 | grep tier1:
run-test-tier1:
test-tier1:
Is this target still available? if so, do we need to update testing.md?
I think the "normal&qu
Hi Abigail,
at some point (it may have been JDK 15, I am not sure atm) we stopped
including the google test framework in our repo and instead require the
builder to provide it externally. See configure option "--with-gtest". Must
point to a copy of the googletest framework (
https://
Hello,
I am attempting to run tests for openjdk15 to 17 using the make target
test-hotspot-gtest, but after compiling the test files, it fails with
this message:
Unknown test selection: 'gtest'
See doc/testing.[md|html] for help
RunTests.gmk:541: *** Cannot continue. Stop.
gt;>
>> Don't we need to mention that the goal of the repeat_count is to run a test
>> until it fails first (to reproduce intermittent issues)?
>
> We can. Current docs copy-pasted the form of `RETRY_COUNT` above. Both should
> be updated with some mention
On Tue, 4 Jan 2022 23:39:45 GMT, Sergey Bylokhov wrote:
>> This adds the test repeat feature in the build system. This is convenient to
>> follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run
>> the test multiple times, until we run out of repe
On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev wrote:
> This adds the test repeat feature in the build system. This is convenient to
> follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run
> the test multiple times, until we run out of repeats or th
On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev wrote:
> This adds the test repeat feature in the build system. This is convenient to
> follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run
> the test multiple times, until we run out of repeats or th
On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev wrote:
> This adds the test repeat feature in the build system. This is convenient to
> follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run
> the test multiple times, until we run out of repeats or th
On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev wrote:
> This adds the test repeat feature in the build system. This is convenient to
> follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run
> the test multiple times, until we run out of repeats or th
On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev wrote:
> This adds the test repeat feature in the build system. This is convenient to
> follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run
> the test multiple times, until we run out of repeats or th
This adds the test repeat feature in the build system. This is convenient to
follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run the
test multiple times, until we run out of repeats or the tests fail.
With this sample test:
/*
* @test
* @run driver IntermittentT
On Thu, 2 Dec 2021 22:45:37 GMT, Magnus Ihse Bursie wrote:
> In JDK-8237858, -pthread was added to all native tests, instead of the one
> single test that needed it. In the meantime, two new tests with pthread
> dependencies has crept in unnoticed due to this.
This pull request has
On Fri, 3 Dec 2021 03:22:03 GMT, David Holmes wrote:
>> In JDK-8237858, -pthread was added to all native tests, instead of the one
>> single test that needed it. In the meantime, two new tests with pthread
>> dependencies has crept in unnoticed due to this.
>
> Looks
On Thu, 2 Dec 2021 22:45:37 GMT, Magnus Ihse Bursie wrote:
> In JDK-8237858, -pthread was added to all native tests, instead of the one
> single test that needed it. In the meantime, two new tests with pthread
> dependencies has crept in unnoticed due to this.
Marked as reviewed
On Thu, 2 Dec 2021 22:45:37 GMT, Magnus Ihse Bursie wrote:
> In JDK-8237858, -pthread was added to all native tests, instead of the one
> single test that needed it. In the meantime, two new tests with pthread
> dependencies has crept in unnoticed due to this.
Looks good.
I do
In JDK-8237858, -pthread was added to all native tests, instead of the one
single test that needed it. In the meantime, two new tests with pthread
dependencies has crept in unnoticed due to this.
-
Commit messages:
- 8251400: Fix incorrect addition of library to test in JDK
On Wed, 20 Oct 2021 18:46:14 GMT, Mikhailo Seledtsov
wrote:
> Please review this trivial change that adds "linux-aarch64" to test make
> profile.
This pull request has now been integrated.
Changeset: af146501
Author:Mikhailo Seledtsov
URL:
https://git.openjdk.jav
On Wed, 20 Oct 2021 18:46:14 GMT, Mikhailo Seledtsov
wrote:
> Please review this trivial change that adds "linux-aarch64" to test make
> profile.
Magnus, thank you for review. The test make build passes on linux-aarch64.
-
PR: https://git.openjdk.java.net/jdk/pull/6051
On Wed, 20 Oct 2021 18:46:14 GMT, Mikhailo Seledtsov
wrote:
> Please review this trivial change that adds "linux-aarch64" to test make
> profile.
Marked as reviewed by ihse (Reviewer).
I assume the tests are passing on aarch64.
-
PR: https://git.openjdk.java.net/jdk/pull/6051
Please review this trivial change that adds "linux-aarch64" to test make
profile.
-
Commit messages:
- Add linux-aarch64 to test make profile
Changes: https://git.openjdk.java.net/jdk/pull/6051/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6051&am
On Mon, 27 Sep 2021 03:26:54 GMT, xpbob
wrote:
> 8274345: make build-test-lib is broken
This pull request has now been integrated.
Changeset: 0865120e
Author:bobpengxie
Committer: Magnus Ihse Bursie
URL:
https://git.openjdk.java.net/jdk/com
On Thu, 23 Sep 2021 22:02:07 GMT, Mikhailo Seledtsov
wrote:
> Please review this small change that adds hook for custom makefiles to
> augment parameters for jtreg test execution.
Thank you Erik !
-
PR: https://git.openjdk.java.net/jdk/pull/5666
On Thu, 23 Sep 2021 22:02:07 GMT, Mikhailo Seledtsov
wrote:
> Please review this small change that adds hook for custom makefiles to
> augment parameters for jtreg test execution.
This pull request has now been integrated.
Changeset: 14100d55
Author:Mikhailo Seledtsov
URL:
On Mon, 27 Sep 2021 03:26:54 GMT, xpbob
wrote:
> 8274345: make build-test-lib is broken
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5710
8274345: make build-test-lib is broken
-
Commit messages:
- 8274345: make build-test-lib is broken
Changes: https://git.openjdk.java.net/jdk/pull/5710/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5710&range=00
Issue: https://bugs.openjdk.java.net/br
On Thu, 23 Sep 2021 22:02:07 GMT, Mikhailo Seledtsov
wrote:
> Please review this small change that adds hook for custom makefiles to
> augment parameters for jtreg test execution.
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5666
Please review this small change that adds hook for custom makefiles to augment
parameters for jtreg test execution.
-
Commit messages:
- Initial change
Changes: https://git.openjdk.java.net/jdk/pull/5666/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5666&
On Thu, 23 Sep 2021 22:02:07 GMT, Mikhailo Seledtsov
wrote:
> Please review this small change that adds hook for custom makefiles to
> augment parameters for jtreg test execution.
Testing:
- tested with custom make file to make sure the feature works
- ran a variety of test fra
0 del; 3 mod
8270422: Test build/AbsPathsInImage.java fails after JDK-8259848
Reviewed-by: mikael
-
PR: https://git.openjdk.java.net/jdk17/pull/249
On Wed, 14 Jul 2021 07:34:58 GMT, Erik Joelsson wrote:
> This patch extends the filter for marker files when creating jmods. Our
> latest established marker file format is `_*.marker` and through
> ExecuteWithLog, we regularly append additional suffixes to such file names.
> Thus I propose we
This patch extends the filter for marker files when creating jmods. Our latest
established marker file format is `_*.marker` and through ExecuteWithLog, we
regularly append additional suffixes to such file names. Thus I propose we
simply extend the filter pattern to `_*.marker*`.
-
says "Building of Hotspot Gtest suite requires the
source code of Google Test framework".
So, I downloaded the source code and reconfigured the Toolchain, adding
-with-gtest to the previously used config command, resulting in:
bash configure --with-boot-jdk=/cygdrive/c/jDev/java-x64/jd
On Wed, 9 Dec 2020 07:11:53 GMT, Hao Sun
wrote:
> Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and
> gcc-6 [2]. Putting the code with proper indentations would suppress this
> warning.
>
> The main reason why test image build with gcc succeeds
On Wed, 9 Dec 2020 07:11:53 GMT, Hao Sun
wrote:
> Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and
> gcc-6 [2]. Putting the code with proper indentations would suppress this
> warning.
>
> The main reason why test image build with gcc succeeds
On Wed, 9 Dec 2020 07:11:53 GMT, Hao Sun
wrote:
> Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and
> gcc-6 [2]. Putting the code with proper indentations would suppress this
> warning.
>
> The main reason why test image build with gcc succeeds
suite requires
the source code of Google Test framework".
So, I downloaded the source code and reconfigured the Toolchain, adding
-with-gtest to the previously used config command, resulting in:
bash configure --with-boot-jdk=/cygdrive/c/jDev/java-x64/jdk-15.0.1+9/
--with-jtreg=/cygdrive/c/
On Fri, 4 Dec 2020 23:01:26 GMT, Erik Joelsson wrote:
> When building the test-bundle incrementally, it always gets rebuilt. This is
> caused by the prepare-test-image target in TestImage.gmk, where we create a
> README file as part of a recipe for a PHONY target. This means that the
On Fri, 4 Dec 2020 23:01:26 GMT, Erik Joelsson wrote:
> When building the test-bundle incrementally, it always gets rebuilt. This is
> caused by the prepare-test-image target in TestImage.gmk, where we create a
> README file as part of a recipe for a PHONY target. This means that the
When building the test-bundle incrementally, it always gets rebuilt. This is
caused by the prepare-test-image target in TestImage.gmk, where we create a
README file as part of a recipe for a PHONY target. This means that the README
is always rebuilt, which in turn triggers downstream rebuilds
On Sat, 5 Sep 2020 09:14:47 GMT, Erik Helin wrote:
> Hi all,
>
> please ignore this "RFR" e-mail, this is just a final test of the Skara [0]
> tooling.
>
> Thanks,
> Erik
>
> [0]: https://openjdk.java.net/projects/skara/
This pull request has
andler.java:68)
> > at
org.openjdk.jmh.runner.BaseRunner.runBenchmark(BaseRunner.java:232)
> > at
org.openjdk.jmh.runner.BaseRunner.doSingle(BaseRunner.java:138)
> > at
org.openjdk.jmh.runner.BaseRunner.runBenchmarksForked(BaseRunner.ja
ksForked(BaseRunner.java:75)
> at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:72)
> at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:84)
>
>
> If I add an extra flag “—enable-preview” , the micro bench will work.
> make test TEST="micro:
at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:84)
>
>
> If I add an extra flag “—enable-preview” , the micro bench will work.
> make test TEST="micro:java.lang.reflect"
MICRO="VM_OPTIONS=--enable-preview"
>
> I am usi
unner.java:75)
at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:72)
at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:84)
If I add an extra flag “—enable-preview” , the micro bench will work.
make test TEST="micro:java.lang.reflect" MICRO="VM_OPT
.openjdk.jmh.runner.BaseRunner.runBenchmarksForked(BaseRunner.java:75)
at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:72)
at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:84)
If I add an extra flag “—enable-preview” , the micro bench will work.
make test TEST=&q
On Fri, 23 Oct 2020 17:18:57 GMT, Aleksey Shipilev wrote:
> Currently, we are only archiving `build/*/test-results`. But hs_errs,
> replays, and test outputs are actually in `build/*/test-support`! Which means
> once any test fails, we only have the summary of the run, not the
git.openjdk.java.net/jdk/commit/888086f1
Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
8255373: Submit workflow artifact name is always "test-results_.zip"
Reviewed-by: rwestberg, ihse
-
PR: https://git.openjdk.java.net/jdk/pull/849
On Sat, 24 Oct 2020 08:35:31 GMT, Aleksey Shipilev wrote:
> The output for the `prerequisites` step is `bundle_id: ${{
> steps.check_bundle_id.outputs.bundle_id }}`, but there is no
> `check_bundle_id` step name to properly reference. Then `artifacts` should
> actually need `prerequisites` to
On Mon, 26 Oct 2020 08:22:47 GMT, Aleksey Shipilev wrote:
>> Currently, we are only archiving `build/*/test-results`. But hs_errs,
>> replays, and test outputs are actually in `build/*/test-support`! Which
>> means once any test fails, we only have the summary of the run, not
> Currently, we are only archiving `build/*/test-results`. But hs_errs,
> replays, and test outputs are actually in `build/*/test-support`! Which means
> once any test fails, we only have the summary of the run, not the bits that
> would actually help to diagnose the problem.
&g
rg
>> - Remove duplicate PATH item
>>
>>Co-authored-by: Robin Westberg
>
> Looks good! I also tried including the entire test-support folder at some
> point, but as you noticed it takes quite a bit of time and space. So this
> approach seems much better.
>
On Fri, 23 Oct 2020 17:18:57 GMT, Aleksey Shipilev wrote:
> Currently, we are only archiving `build/*/test-results`. But hs_errs,
> replays, and test outputs are actually in `build/*/test-support`! Which means
> once any test fails, we only have the summary of the run, not the
On Sat, 24 Oct 2020 08:35:31 GMT, Aleksey Shipilev wrote:
> The output for the `prerequisites` step is `bundle_id: ${{
> steps.check_bundle_id.outputs.bundle_id }}`, but there is no
> `check_bundle_id` step name to properly reference. Then `artifacts` should
> actually need `prerequisites` to
373: Submit workflow artifact name is always "test-results_.zip"
Changes: https://git.openjdk.java.net/jdk/pull/849/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=849&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8255373
Stats: 2 lines in 1 file chang
Currently, we are only archiving `build/*/test-results`. But hs_errs, replays,
and test outputs are actually in `build/*/test-support`! Which means once any
test fails, we only have the summary of the run, not the bits that would
actually help to diagnose the problem.
Archiving the entire
ng tests for both
> the GCs.
This pull request has now been integrated.
Changeset: 96f722cf
Author:Monica Beckwith
Committer: Stefan Karlsson
URL: https://git.openjdk.java.net/jdk/commit/96f722cf
Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod
8252114: Windows-AArch64:
1 - 100 of 810 matches
Mail list logo
