I'm trying to use spring boot 2.3's new support for creating docker images, but the bootBuildImage gradle task is never up-to-date. This unfortunately causes a new docker image to be generated even if no source code was changed.
My goal is to have a static build command that doesn't result in new images being produced unnecessarily. So something like one of the two scenarios below:
./gradlew bootBuildImage (but does nothing if no source code has changed)
OR
./gradlew someOtherTask (if this task is not up-to-date, it triggers bootBuildImage)
My latest effort was to configure bootBuildImage to only run if the bootJar task is not up to date:
tasks {
val bootJarTask: TaskProvider<BootJar> = this.bootJar
bootBuildImage {
outputs.upToDateWhen {
bootJarTask.get().state.upToDate
}
}
}
But this fails with this error (for some reason this particular task hates jars as inputs)
> Unable to store input properties for task ':bootBuildImage'. Property 'jar' with value '/demo/build/libs/demo-0.0.1-SNAPSHOT.jar' cannot be serialized.
Surely I'm missing something obvious here! The reason I need bootBuildImage to only produce an image when necessary is because I've got a multi-project build. I don't want subprojects to generate and push a new image even when nothing in them changed.
Using Spring Boot 2.3.4, Gradle 6.6.1, Java 11.
This seems to work:
val bootJarTask: TaskProvider<BootJar> = this.bootJar
bootBuildImage {
onlyIf {
!bootJarTask.get().state.skipped
}
}
Related
I am working on externalizing our IScheduledExecutorService so I can run tasks externally on a external cluster. I am able to write a test and get the Runnable to actually run ONLY if I turn on UserCode deployment. If I want to change this task at all and run the tests again I get the below in my external cluster member's logs..
java.lang.IllegalStateException: Class com.mycompany.task.ScheduledTask is already in local cache and has conflicting byte code representation
I want to be able to change the task if I could and redeploy to Hazelcast to just handle it. I do this kind of thing with our external maps now. It can handle different versions of our objects using compact serialization.
Am I stuck using user code deployment for these functional objects? If I need to make a change to it I need to change the class name and redeploy to production. I'm hoping to get this task right the first time and not have to ever do that but I have a way of handling it if I do.
The cluster is already running in production and I'll have to add the following to each member
HZ_USERCODEDEPLOYMENT_ENABLED=true
and the appropriate client code(listed below) to enable this.
What I've done...
Added the following to my local docker file
HZ_USERCODEDEPLOYMENT_ENABLED=true
and also in the code that creates a hazelcast client connecting to my external cluster with
ClientConfig clientConfig = new ClientConfig(); ClientUserCodeDeploymentConfig clientUserCodeDeploymentConfig = new ClientUserCodeDeploymentConfig(); clientUserCodeDeploymentConfig.addClass("com.mycompany.task.ScheduledTask"); clientUserCodeDeploymentConfig.setEnabled(true); clientConfig.setUserCodeDeploymentConfig(clientUserCodeDeploymentConfig);
However, if I remove those two pieces I get the following Exception with a failing test. It doesn't know about my class at all.
com.hazelcast.nio.serialization.HazelcastSerializationException: java.lang.ClassNotFoundException: com.mycompany.task.ScheduledTask
Side Note:
We are using compact serialization for several maps already and when I try to configure this Runnable task via compact serialization I get the below error. I don't think that's the right approach either.
[Scheduler: myScheduledExecutorService][Partition: 121][Task: 7afe68d5-3185-475f-b375-5a82a7088de3] Exception occurred during run
java.lang.ClassCastException: class com.hazelcast.internal.serialization.impl.compact.DeserializedGenericRecord cannot be cast to class java.lang.Runnable (com.hazelcast.internal.serialization.impl.compact.DeserializedGenericRecord is in unnamed module of loader 'app'; java.lang.Runnable is in module java.base of loader 'bootstrap')
at com.hazelcast.scheduledexecutor.impl.ScheduledRunnableAdapter.call(ScheduledRunnableAdapter.java:49) ~[hazelcast-5.2.0.jar:5.2.0]
at com.hazelcast.scheduledexecutor.impl.TaskRunner.call(TaskRunner.java:78) ~[hazelcast-5.2.0.jar:5.2.0]
at com.hazelcast.internal.util.executor.CompletableFutureTask.run(CompletableFutureTask.java:64) ~[hazelcast-5.2.0.jar:5.2.0]
Me and my team just moved from JUnit4 to JUnit5 and we faced with parallelism issues. With 4th version we used -Dcucumber.options="--threads 5" to run in tests several threads, but after deprecation and removing of cucumber options it's obviously doesn't work anymore. I set up (at least I think so) junit platform engine for the project (https://github.com/cucumber/cucumber-jvm/tree/main/cucumber-junit-platform-engine#configuration-options), but when I try to run tests via comand line (using Gradle task), I receive following error:
UnknownClass.Cucumber > UnknownClass.initializationError FAILED
org.junit.platform.commons.JUnitException at EngineExecutionOrchestrator.java:114
Caused by: org.junit.platform.commons.JUnitException at HierarchicalTestEngine.java:57
Caused by: org.junit.platform.commons.JUnitException at DefaultParallelExecutionConfigurationStrategy.java:41
Unfortunately, didn't find something in the internet, maybe someone can help with it?
What we use:
Spring boot 2.7.3
Gradle 7.5.1
Cucumber java, junit, spring, junit-platform-engine 5.7.0
junit-platform-suite-api 1.3.2
Tasks in build.gradle that I have now:
useJUnitPlatform()
systemProperty("cucumber.junit-platform.naming-strategy", "long")
systemProperty("cucumber.execution.parallel.enabled", true)
systemProperty("cucumber.execution.parallel.config.strategy", "fixed")
systemProperty("cucumber.plugin", "html:reports/html")
systemProperty("cucumber.plugin", "pretty")
systemProperty("cucumber.plugin", "junit:reports/junit")
doLast {
javaexec {
mainClass.set("io.cucumber.core.cli.Main")
classpath = cucumberRuntime + sourceSets.test.get().output + sourceSets.main.get().output
}
}
}
tasks {
val consoleLauncherTest by registering(JavaExec::class) {
dependsOn(testClasses)
val reportsDir = file("$buildDir/test-results")
outputs.dir(reportsDir)
classpath = sourceSets["test"].runtimeClasspath
mainClass.set("org.junit.platform.console.ConsoleLauncher")
args("--scan-classpath")
args("--include-engine", "cucumber")
args("--reports-dir", reportsDir)
}
test {
dependsOn(consoleLauncherTest)
exclude("**/*")
}
}
Configuration class:
#CucumberContextConfiguration
#Suite
#IncludeEngines("cucumber")
#SelectClasspathResource("com/example")
#ConfigurationParameter(key = GLUE_PROPERTY_NAME, value = "com.example")
#SpringBootTest
#ContextConfiguration(classes = [IntegrationContext::class], loader = SpringBootContextLoader::class)
class Application() {}
Your question is pretty much impossible to answer because you didn't go through the process of making a minimal reproducer. For your next question please read the "Help others reproduce the problem" section in How do I ask a good question?.
With 4th version we used -Dcucumber.options="--threads 5" to run in tests several threads, but after deprecation and removing of cucumber options it's obviously doesn't work anymore.
Project typically include a CHANGELOG and release notes documenting all relevant changes.
What we use:
Spring boot 2.7.3
Cucumber java, junit, spring, junit-platform-engine 5.7.0
junit-platform-suite-api 1.3.2
These dependencies don't converge and aren't quite correct. You'll want to use Cucumber's and JUnit's Bill of Materials to avoid having to specify the version for every module.
If you're using Spring Boot in the recommended way you may also be able to omit the junit-bom altogether.
dependencies {
testImplementation(platform("org.junit:junit-bom:5.9.1"))
testImplementation(platform("io.cucumber:cucumber-bom:7.9.0"))
testImplementation("io.cucumber:cucumber-java")
testImplementation("io.cucumber:cucumber-junit-platform-engine")
testImplementation("org.junit.platform:junit-platform-suite")
testImplementation("org.junit.jupiter:junit-jupiter")
}
Tasks in build.gradle that I have now:
So in this build file it appears that you are trying to run Cucumber in 3 different ways. Through the JUnit Platform, through Cucumbers CLI and through the JUnit 5 ConsoleLauncher.
I don't know which solution you are trying use but suppose that you want to use the JUnit Platform, then you look at cucumber-java-skeleton for a working example.
Then afterwards you should clean up your build file. :D
I had a groovy code wich contains "import groovy.json.JsonSlurper".
I have spent a day testing and i dont know how to load external libraries using declarative syntax.
This is my code:
pipeline {
agent any
import groovy.json.JsonSlurper
stages {
stage("test") {
steps {
}
}
}
}
I have read the jenkins documentation, and i have tried to use the next but without success:
#Grab('groovy.json.JsonSlurper')
import groovy.json.JsonSlurper
both import and #Grab is not recognized. Some idea?
Thanks!
What #Daniel Majano says is true about the import syntax, but the #Grab syntax I found holds differences of behavior between a Pipeline script maintained directly in Jenkins vs Pipeline script from SCM.
When I placed a Grab command in the Pipeline script for a tester pipeline job I found that it didn't make any difference whether the Grab command was there or if it was commented out.
However when used from a Pipeline script from SCM it would throw the following exception...
java.lang.RuntimeException: No suitable ClassLoader found for grab
I removed it from the SCM script and everything worked out in the end.
Additional Background
I'm not sure why the grab was choking in the SCM version, but there's definitely some working parts to the groovy editor because if you define a partial grab command it will give you some validation errors pointing to the broken line as you see in the red X box below, with the error The missing attribute "module" is required in #Grab annotations:
Therefore the script validator is aware of the Grab annotation as it calls it and that it has both a group and module attribute. I'm using the so called shorthand notation in this example.
I found that my Sonar instance 5.1 or 5.1.1 (with latest sonar-runner 2.x) stopped showing part of the Unit test info (Unit test widget) on the project's dashboard.
The properties I had were (in Gradle's sonarRunner > sonarProperties section):
property "sonar.junit.reportsPath", "build/test-results/UT"
property "sonar.surefire.reportsPath", "build/test-results/UT"
To fix it, I had to include the following properties as well:
property "sonar.java.junit.reportsPath", "build/test-results/UT"
property "sonar.java.surefire.reportsPath", "build/test-results/UT"
Just FYI: All my Unit tests reports go under build/test-results/UT folder, all Integration Tests result files go unedr build/test-results/IT folder and etc.
I'm wondering if this is due to Gradle version that I'm using (2.3) or is it due to a later version of SonarQube (4.5+) as I have both SQ 5.1 and 5.1.1 instance.
I know SonarQube team started Multi language support since SonarQube version 4.12
Since SonarQube 4.2, it is possible to run an analysis on a multi-language project.
Now, it raises a question. For Getting the same Unit test info for Groovy based projects, do I need to use:
property "sonar.groovy.junit.reportsPath", "build/test-results/UT"
property "sonar.groovy.surefire.reportsPath", "build/test-results/UT"
something like that if my project has Groovy code instead of java?
Searching "**sonar.java.junit.reportPath"** with using double quotes shows No results found in Google and it forces me to try and see google results if I can run the search again without using " double quotes (for this property).
Doing the same in SonarQube site "search box" shows:
No results found for sonar.java.junit.reportPath. Please try one of the following suggestions:
Though in Gradle, inside
sonarRunner task {
.. inside ..
sonarProperties {
... section ... where I define various sonar props..
}
...
}
I can define both sonar.junit.reportPath, sonar.java.junit.reportPath and similarly, sonar.surefire.reporPath and sonar.java.surefire.reportPath and while running sonarRunner task in Gradle, it doesn't error out. Thus it makes me believe that the property variables are valid.
There are also issues with running sonarRunner or stand alone sonar-runner command for a mixed Java and Groovy based project (i.e. source code in Java but tests in Groovy). Setting sonar.language=java,grvy didn't help. I posted this question on stackoverflow but so far I have no perfect result/answer on how to get a full fledged sonar dashboard up and running for a Groovy projects like I get for a Java project.
Groovy project - Sonar - Publish project and Unit + Integration Test code coverage data
PS: I have tried various values for setting sonar.. variables (as far a sonar source, tests, etc, etc properties are concerned, which they have mentioned on their site's docs section)
The only valid property to use as of now is sonar.junit.reportsPath which will tell the java sonarqube plugin where to import your result of unit tests.
For groovy, this is work in progress, see : http://jira.sonarsource.com/browse/SONARGROOV-2
All the other properties you mentioned do not exist and are not taken into account.
I need your help !
I want to know how do Hudson generate a job's config.xml?
I explain: I want to add in my application a hudson-like build tool, to do this, a user will have, like in Hudson's GUI, define some parameters like path to jdk, where the pom.xml is stored, etc... and then the config.xml for this job is generated.
Once i will have the config.xml for this job, i will create and build it.
I tried to search for Hudson's API, but it's all about creating a job, building, deleting.. but no way to give it parameters (personalize it). This is a "create" code sample:
private void put(HttpClient client, String hudsonBaseURL,String jobName ,File configFile) throws IOException, HttpException {
PostMethod postMethod = new PostMethod(hudsonBaseURL+ "/createItem?name=" + jobName);
postMethod.setRequestHeader("Content-type","application/xml; charset=ISO-8859-1");
postMethod.setRequestBody(new FileInputStream(configFile));
postMethod.setDoAuthentication(true);
try {
int status = client.executeMethod(postMethod);
System.out.println("Projet existe déjà\n"+status + "\n"+ postMethod.getResponseBodyAsString());
} finally {
postMethod.releaseConnection();
}
}
This method requires the config.xml to create a job.
I'm now trying to see the content of the hudson.war, inside its classes, but i have to say that this is not easy.
I wish i was clear.
Any idea would be welcome.
Nacef.
I recommend using Hudson's remote API for automating creation of a job.
Have a look at http://your.hudson.server/api. Hudson will return HTML documentation for the remote API. Under Create Job you'll see that you can POST a config.xml to a Hudson URL in order to create a job. You should be able to create a template job manually, then use that config.xml as a template in your automated system.
As described in this previous answer, job configuration can be found in HUDSON_HOME/jobs/[name]/config.xml.