Testing

This page describes how do testing with the help of GitHub Actions.

GitHub Actions

GitHub Actions is a way to describe workflows that should be triggered when certain events occur, such as the push of a commit to personal fork. For contributors that have a personal fork of the jdk repository then builds and tests will be executed when a commit is pushed to the contributor's personal fork.

Configuring workflows to run

When you create a new personal fork of the jdk repository, GitHub Actions are disabled by default. When you visit the Actions tab for your personal fork, you will see a message similar to this: "Workflows aren't being run on this forked repository". Click on the green button labelled "I understand my workflows, go ahead and enable them" to allow the jdk builds and tests to execute for branches in your personal fork.

Triggering builds and tests

When GitHub Actions are enabled for a personal fork, the builds and tests will be automatically run whenever a contributor pushes a commit to a branch in their personal fork. Contributors can also manually re-run the actions for a certain commit, see the GitHub documentation for details.

Analyzing results

If a contributor has run testing with the help of GitHub Actions then the Skara bots will automatically display a summary of the build and test results in checks area. Please see the GitHub documentation for how to view the logs from a build and/or test run. Additional output from the test execution is preserved as a artefact that can be downloaded.

Conditionally enable/disable builds and tests

Contributors who wishes to push commits to their personal fork without triggering automatic builds and tests being run can do so by opting out from automatic testing. A contributor who wishes to disable automatic builds and tests for all changes can disable GitHub Actions for their personal fork. See the GitHub documentation for how to disable GitHub Actions completely for a repository.

Contributors can choose to only enable automatic builds and tests for commits pushed to branches whose names are prefixed with submit/. To enable this the contributors creates a GitHub Secret with the name JDK_SUBMIT_FILTER. The value of JDK_SUBMIT_FILTER should be set to a non-empty string, preferably something random (instead of 1 or true) as the GitHub log viewer will hide any occurrences of this string (as it could potentially be an actual secret like a password). When this is set, testing can be triggered manually by a command such as this:

git push origin <name-of-my-branch>:submit/<name-of-my-branch>	# Replace <name-of-my-branch> with an actual branch name

It is also possible to only run tests on a subset of platforms. To enable this the contributors creates a GitHub Secret with the name JDK_SUBMIT_PLATFORMS. The value of JDK_SUBMIT_PLATFORMS should be set to a string listing the enabled platforms. Include one or more of the following platform names:

• Linux x64
• Linux x86
• Linux additional (hotspot only)
• Windows x64
• macOS x64

Running locally

The run the same tests that are being run using GitHub Actions locally, run the following command:

make test-tier1

Note that the GitHub Actions runs the above tests both with release and debug builds. For more information about how to run tests locally, see doc/testing.md.

Definitions

The definitions for the GitHub Actions for the jdk repository are available in the .github/workflows directory.

Builds

GNU/Linux

x86-64

• Release
• Debug ("fastdebug")
• Release without precompiled headers

macOS

x86-64

• Release
• Debug ("fastdebug")

Windows

x86-64

• Release
• Debug ("fastdebug")

Tests

tier1

• GNU/Linux x86-64
• macOS x86-64
• Windows x86-64