Some actions require Java to run, like the package and export actions. GitHub-hosted runners come with multiple Java versions pre-installed, but the default version may not be compatible with the (Java) software to be packaged, or with our tools (ScanCentral Client. FortifyVulnerabilityExporter).
For example, Windows runners have Java 8 as default, which is incompatible with ScanCentral Client. Not sure why our actions currently run successfully on Windows runners, either ScanCentral Client manages to pick up one of the other pre-installed Java versions, or maybe GitHub documentation is wrong.
Anyway, default/available Java version(s) on runners may change at any time (and self-hosted runners may not even have Java pre-installed), so we should document this requirement, and add the Java setup action to sample workflows. This should be done for both the individual sub-actions that require Java, and the composite actions that use these sub-actions, like fortify/github-action, fortify/github-action/fod-sast-scan and fortify/github-action/sc-sast-scan.
Alternatively, we could add the setup-java action to the appropriate sub-actions, but not sure whether that's a good idea as this may override any Java setup done by the calling workflow. Maybe we can detect whether setup-java was already called by the calling workflow (with a supported Java version), and only call setup-java if it wasn't called by the calling workflow?
Some actions require Java to run, like the package and export actions. GitHub-hosted runners come with multiple Java versions pre-installed, but the default version may not be compatible with the (Java) software to be packaged, or with our tools (ScanCentral Client. FortifyVulnerabilityExporter).
For example, Windows runners have Java 8 as default, which is incompatible with ScanCentral Client. Not sure why our actions currently run successfully on Windows runners, either ScanCentral Client manages to pick up one of the other pre-installed Java versions, or maybe GitHub documentation is wrong.
Anyway, default/available Java version(s) on runners may change at any time (and self-hosted runners may not even have Java pre-installed), so we should document this requirement, and add the Java setup action to sample workflows. This should be done for both the individual sub-actions that require Java, and the composite actions that use these sub-actions, like
fortify/github-action,fortify/github-action/fod-sast-scanandfortify/github-action/sc-sast-scan.Alternatively, we could add the
setup-javaaction to the appropriate sub-actions, but not sure whether that's a good idea as this may override any Java setup done by the calling workflow. Maybe we can detect whethersetup-javawas already called by the calling workflow (with a supported Java version), and only callsetup-javaif it wasn't called by the calling workflow?Also see https://github.com/orgs/community/discussions/73309