- 14 Jun, 2019 1 commit
-
-
Steve Blackburn authored
-
- 03 Apr, 2019 1 commit
-
-
Sichao Li authored
-
- 01 Nov, 2018 1 commit
-
-
John Zhang authored
- fix: eclipse benchmark had the wrong (old) MD5s - fix: missing and old MD5s for Jython downloads - fix: broken link for NSIS 3 - remove Maven memory restriction, which caused build to fail on weasel.moma - add CI caching - use small size when testing runnability on CI - add ability to clone and checkout from git repo - display warning message if build is not a release build
-
- 20 May, 2018 1 commit
-
-
Steve Blackburn authored
Improved README
-
- 18 May, 2018 1 commit
-
-
Noric Couderc authored
Added a section on how to use callbacks.
-
- 10 May, 2018 1 commit
-
-
Steve Blackburn authored
Version bump for all 9.12 benchmarks, validated on OpenJDK 8
-
- 30 Apr, 2018 1 commit
-
-
John Zhang authored
-
- 27 Apr, 2018 5 commits
-
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
The problem was because Geronimo server wants to read from stdin. GitLab runner doesn't provide stdin, so it just reads an EOF and quits. This is why GBeans is not running. Thus the solution is to keep stdin open for the duration of the benchmark. Setting a time out (120 seconds) with `sleep` command seems to work. NOTE: this value may need to be modified on slower machines.
-
John Zhang authored
When trying to locally test the CI problem, there was another issue with running gitlab-runner locally. It seems that during the deploy stage of building DayTrader, Geronimo tries to execute `stty -icanon min 1 < /dev/tty` command. It causes the whole thing to hang. The reason might be that tty is not enabled in gitlab-runner. I found a hacky [solution ](https://gitlab.com/gitlab-org/gitlab-runner/issues/1021) that uses the script command to emulate tty. And it seems to work.
-
John Zhang authored
Callback path fix See merge request !11
-
- 23 Apr, 2018 1 commit
-
-
John Zhang authored
-
- 21 Apr, 2018 1 commit
-
-
John Zhang authored
-
- 20 Apr, 2018 3 commits
-
-
John Zhang authored
If batik is built before fop, fop's lib dependency on batik will overwrite the patched batik jar. There was a previous commit that attempts to deal with the issue, but it created dependency not found problem when fop is the only one built. This commit properly deals with the issue by renaming the batik jar that fop depends on, thus not overwriting the patched batik benchmark.
-
John Zhang authored
-
John Zhang authored
The path for harness in the target dacapo.jar has been put under the harness/ prefix. This caused incompatibility problems with previous releases. This commit fixes this problem.
-
- 11 Apr, 2018 1 commit
-
-
John Zhang authored
-
- 06 Apr, 2018 1 commit
-
-
Rui Chen authored
-
- 30 Mar, 2018 1 commit
-
-
Rui Chen authored
-
- 29 Mar, 2018 6 commits
-
-
Rui Chen authored
-
Rui Chen authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
- 28 Mar, 2018 4 commits
-
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
Fop carries a batik-all-1.9.jar with it, which will overwrite the batik benchmark jar when unzipped into scratch directory, rendering the patch to batik 1.9 ineffective. Fop benchmark doesn't seem to actually use the jar. So removing it from the list of jars to include in fop doesn't affect running fop benchmark, and batik is now fine.
-
- 27 Mar, 2018 10 commits
-
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-
John Zhang authored
-