I have created a GitHub actions script and in 2nd run, the cache step is used. However, the version that is cached was 17 but upon checking the version with java -version it shows version 1.8
openjdk version "1.8.0_352"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_352-b08)
OpenJDK 64-Bit Server VM (Temurin)(build 25.352-b08, mixed mode)
how do I do cache this particular version of java? thanks in advance.
my complete script.
name: dotnet-pipeline
on: [push]
jobs:
build:
name: Build-run-analysis
runs-on: windows-2022
env:
JAVA_HOME: 'C:\hostedtoolcache\windows\Java_Microsoft_jdk\17.0.3\x64'
JAVA_HOME_17_X64: 'C:\hostedtoolcache\windows\Java_Microsoft_jdk\17.0.3\x64'
steps:
- name: Cache JDK
id: cache-jdk
uses: actions/cache#v3
with:
path: ${{ env.JAVA_HOME }}
key: ${{ runner.os }}-jdk-17
restore-keys: |
${{ runner.os }}-jdk-
# Install Java development kit using microsoft distro
- name: Install Java
if: steps.cache-jdk.outputs.cache-hit != 'true'
uses: actions/setup-java#v3
with:
distribution: 'microsoft'
java-version: '17'
check-latest: false # enforce to use files from cache
- name: Set PATH
run: |
echo "${{ env.JAVA_HOME }}" | Out-File -FilePath $ENV:GITHUB_PATH -Encoding utf8 -Append
- name: check version
run: java -version
It turned out to be quite similar to your earlier question about the dotnet caching:
How to cache dotnet installation in GitHub Actions
The only thing is to cache the correct installed path and set it to GITHUB_PATH when the cache is hit.
JAVA_HOME_17_X64 will be:
C:\hostedtoolcache\windows\Java_Microsoft_jdk\17.0.3\x64
And, its bin subdirectory will be added to GITHUB_PATH:
${{ env.JAVA_HOME_17_X64 }}\bin
Here's the complete workflow:
name: cache_java
on:
workflow_dispatch:
jobs:
build:
runs-on: windows-2022
env:
JAVA_HOME_17_X64: 'C:\hostedtoolcache\windows\Java_Microsoft_jdk\17.0.3\x64'
steps:
- name: Cache JDK
id: cache-jdk
uses: actions/cache#v3
with:
path: ${{ env.JAVA_HOME_17_X64 }}
key: ${{ runner.os }}-jdk-17
restore-keys: ${{ runner.os }}-jdk-
- name: Install Java
if: ${{ steps.cache-jdk.outputs.cache-hit != 'true' }}
uses: actions/setup-java#v3
with:
distribution: 'microsoft'
java-version: '17'
- name: Check default Java version
run: java -version
- name: Set installed/cached Java path [${{ env.JAVA_HOME_17_X64 }}]
run: echo "${{ env.JAVA_HOME_17_X64 }}\bin" | Out-File -FilePath $ENV:GITHUB_PATH -Encoding utf8 -Append
- name: Check installed/cached Java version
run: java -version
Output:
Related
I am trying to set up a workflow for my project. I used the standard "Configure with gradle" workflow, and just edited the java version from 11 to 17.
But when I push my code, it throws an error:
this is my workflow so far
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-gradle
name: Java CI with Gradle
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
permissions:
contents: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3
- name: Setup jdk-17
uses: actions/setup-java#main
with:
java-version: 17
distribution: 'adopt'
- name: Build with Gradle
uses: gradle/gradle-build-action#0d13054264b0bb894ded474f08ebb30921341cee
with:
arguments: ./gradlew build
Gradle User Home cache not found. Will initialize empty.
Error: Error: Gradle script '/home/runner/work/Slapbot-stewie/Slapbot-stewie/gradlew' is not executable.
I do not know how to fix this error, I found no relevant google search that can help with this.
Arguments is just build since you are using the gradle actions instead of the ./gradlew :
- name: Build with Gradle
uses: gradle/gradle-build-action#0d13054264b0bb894ded474f08ebb30921341cee
with:
arguments: build
I have created a GitHub package and created releases with GitHub actions for a simple Hello-world mule application.
name: GitHub Packages and Releases using Java CI with Maven
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Set up JDK 11
uses: actions/setup-java#v1
with:
java-version: 11
- name: Build with Maven
run: mvn -B package --file pom.xml
Publish:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Set up JDK 11
uses: actions/setup-java#v1
with:
java-version: '11'
- name: Create GitHub Release
uses: actions/create-release#v1
env:
GITHUB_TOKEN: ${{secrets.GIT_TOKEN}}
with:
tag_name: v${{github.run_number}}
Now I wanted to download the jar file from the GitHub package or extract zip folder (source code.zip) from Releases and deploy the jar file to cloud hub using Maven GitHub actions.
Thanks in Advance
You can't use Mule Maven plugin to publish an existing jar to CloudHub. It only supports publishing what's being built with Maven. You can use instead Anypoint CLI. For example with the command runtime-mgr cloudhub-application deploy you can deploy a jar file to CloudHub.
Running mvn -v returns this error only in git bash:
Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher
In windows cmd:
C:\Users\ross>mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T12:00:29-07:00)
Maven home: C:\Program Files\apache-maven-3.6.1\bin\..
Java version: 1.8.0_221, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_221\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
In git bash:
$ echo $PATH
... :/c/Program Files/Java/jdk1.8.0_221/bin: ... :/c/Program Files/apache-maven-3.6.1/bin: ...
$ echo $JAVA_HOME
C:\Program Files\Java\jdk1.8.0_221
$ which mvn
/c/Program Files/apache-maven-3.6.1/bin/mvn
Reinstalling git bash didn't fix it
Redownloading maven didn't work either
M2_HOME, M3_HOME, MAVEN_HOME is unset
Try moving the MAVEN_HOME variable up in your environment variables
I fail to build guava v21.0 as the test concurrent.ListenerCallQueueTest hangs for ever:
$ git clone https://github.com/google/guava
$ cd guava
$ git tag
$ git checkout v21.0
$ mvn package
[...]
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.177 sec
Running com.google.common.util.concurrent.ListenerCallQueueTest
It seems I have three sleeping processes:
$ ps aux | grep guava | grep -v grep
john 23619 16.6 12.5 4531216 1016192 pts/1 Sl+ 07:47 4:43 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -classpath /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dclassworlds.conf=/usr/share/maven/bin/m2.conf -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/home/john/Libs/guava org.codehaus.plexus.classworlds.launcher.Launcher clean install
john 26401 0.0 0.0 4292 756 pts/1 S+ 07:55 0:00 /bin/sh -c cd /home/john/Libs/guava/guava-tests && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Xmx1536M -Duser.language=hi -Duser.country=IN -jar /home/john/Libs/guava/guava-tests/target/surefire/surefirebooter6901955962891879666.jar /home/john/Libs/guava/guava-tests/target/surefire/surefire4499145904440222523tmp /home/john/Libs/guava/guava-tests/target/surefire/surefire2603198880854108081tmp
john 26403 68.8 14.4 4137984 1167932 pts/1 Sl+ 07:55 14:07 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Xmx1536M -Duser.language=hi -Duser.country=IN -jar /home/john/Libs/guava/guava-tests/target/surefire/surefirebooter6901955962891879666.jar /home/john/Libs/guava/guava-tests/target/surefire/surefire4499145904440222523tmp /home/john/Libs/guava/guava-tests/target/surefire/surefire2603198880854108081tmp
This situation occurs on my debian stretch machine:
$ uname -a
Linux front 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Linux
$ mvn -version
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.8.0-1-amd64", arch: "amd64", family: "unix"
The same procedure leads to a successful build on my debian jessie machine:
Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.8.0_111, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "3.16.0-4-amd64", arch: "amd64", family: "unix"
Following suggestions found in this post I have achieved a successful build with:
$ mvn clean install -Dmaven.test.skip
However running mvn clean install instead of mvn clean package leads to the same result.
Any suggestion is greatly appreciated.
I want to install the Chef maven cookbook from the community site, and select java version 7. To do so I have added the following attributes in the attributes/default.rb of my recipe.
# Configure java and maven
default['maven']['setup_bin'] = true
node.override[:java][:jdk_version] = '7'
node.override[:java][:openjdk_packages] = [
"openjdk-7-jdk", "openjdk-7-jre-headless"
]
This does not work, as it installs java version 6. I have tried other variants with the same result, such as:
# Configure java and maven
default['maven']['setup_bin'] = true
default['java']['jdk_version'] = '7'
My platform is an Ubuntu precise64.
The output of mvn -v is the following:
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09 17 15:22:22+0000)
Maven home: /usr/local/maven
Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "3.2.0-23-generic", arch: "amd64", family: "unix"
How can I tell the java cookbook to install version 7?
Thanks!
Daniel
Your code is not working because you have not set the node['java']['openjdk_version'] attribute. Here is the relevant code segment:
node['java']['openjdk_packages'].each do |pkg|
package pkg do
version node['java']['openjdk_version'] if node['java']['openjdk_version']
end
end
Another option would be not to set the node['java']['openjdk_packages'] attribute. The set_attributes_from_version recipe contains logic to do this based on the OS.