I need to know the teamcity settings which prevents the re-trigger/trigger of outdated builds/jobs if the new builds are successful.
I am facing a issue where teamcity jobs can be re triggered even if the next builds are successful.And If the trigger event is fired before, then it must stop teamcity to run that job if the latest build is successful.
So I have to 2 jobs in TC for 1 branch -- Build-Precheck and the other is Build-compile
So I could see that Build-compile is just picking the latest available successful build from Build-Precheck and then queing up the next which may be the outdated build.
Build-Precheck is just taking 2 min to finish the builds , it quickly triggers the latest builds , I guess following the principal First In First Out
Build-Precheck
06 Oct 14 14:33 - 14:35 (2m:01s) –7.1.4345
06 Oct 14 14:41 - 14:43 (2m:16s)- 7.1.4346
06 Oct 14 14:45 - 14:47 (2m:10s)- 7.1.4347
Build-compile
06 Oct 14 14:35 - 15:00 -7.1.0.4345
06 Oct 14 14:52 - 15:20 (28m:02s)- 7.1.4347
06 Oct 14 16:08 - 16:33 (24m:52s)- 7.1.4346
Is there any fix for this that TC runs incremental builds rather than outdated ones
Sounds like you are looking for Configuring Build Trigger.
AFAIK, there isn't a way to cancel queued builds if a given build passes. However, you can adjust the Build Triggers that queue those builds. Most likely, you'll need to set the Quiet Period on your VCS Build Trigger to longer than it takes for your build.
For example, if your full build takes 5 minutes, you should set the Quiet Period to 7. This way additional builds wont queue while a build is running.
Related
When I am passing the command in command prompt then I am getting the below error-
C:\Users\ShivangiT\Downloads\apache-jmeter-5.3\apache-jmeter-5.3\bin>Jmeter.bat -Jjmeter.save.saveservice.output_format=xml -n -t \Users\ShivangiT\Downloads\apache-jmeter-5.3\apache-jmeter-5.3\bin\vieweventpage.jmx -l \Users\ShivangiT\Downloads\apache-jmeter-5.3\apache-jmeter-5.3\bin\rr.jtl
Creating summariser <summary>
Created the tree successfully using \Users\ShivangiT\Downloads\apache-jmeter-5.3\apache-jmeter-5.3\bin\vieweventpage.jmx
Starting standalone test # Fri Aug 21 07:29:38 BST 2020 (1597991378434)
Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445
summary = 41 in 00:00:14 = 2.9/s Avg: 5256 Min: 7 Max: 13688 Err: 13 (31.71%)
Tidying up ... # Fri Aug 21 07:29:52 BST 2020 (1597991392905)
... end of run
The JVM should have exited but did not.
The following non-daemon threads are still running (DestroyJavaVM is OK):
Thread[DestroyJavaVM,5,main], stackTrace:
Thread[AWT-EventQueue-0,6,main], stackTrace:sun.misc.Unsafe#park
java.util.concurrent.locks.LockSupport#park
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#await
java.awt.EventQueue#getNextEvent
java.awt.EventDispatchThread#pumpOneEventForFilters
java.awt.EventDispatchThread#pumpEventsForFilter
java.awt.EventDispatchThread#pumpEventsForHierarchy
java.awt.EventDispatchThread#pumpEvents
java.awt.EventDispatchThread#pumpEvents
java.awt.EventDispatchThread#run
Thread[AWT-Shutdown,5,system], stackTrace:java.lang.Object#wait
sun.awt.AWTAutoShutdown#run
java.lang.Thread#run
Can anybody please help me with this.
This is a known issue of JMeter 5.3 when test plan contains Http(s) Test script recorder.
The workaround is to remove it.
See:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64479
Alternatively you can try nightly build:
https://ci.apache.org/projects/jmeter/nightlies/
Shiva, I would suggest that you should use the older version of JMeter always. The reason is very simple. There is not much of a change in JMeter since JMeter 4. JMeter is more inclined towards its compatibility with JDK 11 as currently, it supports JDK 8 flawlessly in the older versions. Use JMeter 4 from the JMeter official archive and you'll be able to execute everything smoothly. No need to look for workarounds. Make sure you use JMeter 4
I start off by deleting Gradle's build cache
$ rm -rf $GRADLE_HOME/caches/build-cache-*
I manually confirm this directory is gone. I also clean to ensure nothing from incremental build will interfere
$ ./gradlew clean
I then run a build w/ build-cache enabled:
$ ./gradlew --build-cache --scan app:assembleDebug
...
238 actionable tasks: 172 executed, 49 from cache, 17 up-to-date
Checking the generated report I see that some tasks are still marked as FROM-CACHE. How is this happening?
FWIW I'm using Gradle 5.6.3. I also don't use a remote build cache.
UPDATE: after clearing build cache, here's what's left in the cache dir:
$ pwd
/Users/jasonatwood/.gradle/caches
$ ls -al
total 24
drwx------ 11 jasonatwood staff 352 Dec 13 18:11 .
drwxr-xr-x 9 jasonatwood staff 288 Oct 15 17:24 ..
drwxr-xr-x 14 jasonatwood staff 448 Oct 29 16:07 5.4.1
drwxr-xr-x 15 jasonatwood staff 480 Nov 26 18:25 5.6.3
drwxr-xr-x 35 jasonatwood staff 1120 Dec 11 14:14 jars-3
drwxr-xr-x 5 jasonatwood staff 160 Oct 15 17:44 journal-1
drwxr-xr-x 7 jasonatwood staff 224 Oct 15 17:50 modules-2
drwxr-xr-x 5 jasonatwood staff 160 Oct 15 17:50 transforms-2
-rw-r--r-- 1 jasonatwood staff 39 Oct 15 17:27 transforms-2.lock
-rw------- 1 jasonatwood staff 28 Oct 22 16:34 user-id.txt
-rw-r--r-- 1 jasonatwood staff 17 Dec 13 18:00 user-id.txt.lock
If I understand correctly, I don't need to delete any of these.
The local task cache in the .gradle directory within the root project might interfere.
In order to disable the local/global caching altogether, use gradle.properties:
org.gradle.caching=false
If you remove the local build cache and don't use a remove cache, Gradle should indeed not be able to fetch anything cached on the next build. However, I don't think you actually removed anything.
The GRADLE_HOME environment variable, if you have it, should points to an unpacked local Gradle distribution. It could be something like /Users/jasonatwood/gradle-6.0-all. It would be wrong to set it to a path that is not a Gradle distribution.
The Gradle build cache resides in /Users/jasonatwood/.gradle/caches/build-cache-1.
When you try to remove it with $ rm -rf $GRADLE_HOME/caches/build-cache-*, you are using GRADLE_HOME as if it is pointing to the root of your home folder (/Users/jasonatwood), which it most likely isn't.
So instead, use this for removing it: $ rm -rf ~/.gradle/caches/build-cache-*
Or, at the very least, verify that the cache folder has indeed been removed.
If I run a --scan and look at the FROM-CACHE tasks in the generated HTML report.
I then look at the build cache keys for those FROM-CACHE tasks. I then go find those keys on my local machine. I see they are generated at the same time as the rest of the build. So I'm guessing that Gradle is using build cache within a build and not just across builds.
Sometimes there is a need to invalidate cache every time you restart the IDEA. This may be due to shared indexes reuse. What I did Settings --> Tools --> Shared Indexes -> Download Automatically and it resolved all the pain.
Earlier the setting was Don't download use Local.
I hit a strange problem with potentially broken stale frameworks garbage collection on mesos slaves (1.9.0-2.0.1.debian8).
As per documentation stale frameworks should be automatically deleted if are not accessed for predefined time period, however while in slave log I could see slave is running out of storage, there are still framework folders dated more than week old.
I have following values set for garbage collection:
--disk_watch_interval="1mins"
--gc_delay="2days"
--gc_disk_headroom="0.2"
$ date
Thu Nov 7 13:32:50 UTC 2019
$ tail -20 /srv/mesos/agent/logs/mesos-slave.INFO |grep 'Max allowed'
I1107 13:32:33.576203 27465 slave.cpp:7406] Current disk usage 71.83%. Max allowed age: 3.923527125292778hrs
$ ls -l --time=atime /srv/mesos/agent/slaves/bcb34071-9fd8-481a-8d0c-767ef0628216-S2/frameworks/ |grep Oct|tail -5
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0004
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0005
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0007
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0008
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0009
Any idea for a reason that can happen and a way to force garbage collection (except adjusting gc_delay to zero and restarting mesos slave)?
What frameworks are you using? Maybe you need to set -gc_non_executor_container_sandboxes
A new --gc_non_executor_container_sandboxes agent flag has been added to garbage collect the sandboxes of nested containers, which includes the tasks groups launched by the default executor. We recommend enabling the flag if you have frameworks that launch multiple task groups on the same default executor instance.
I installed the OpenJDK via Nix in Ubuntu (Linux uplink 4.13.0-32-generic #35~16.04.1-Ubuntu SMP Thu Jan 25 10:13:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux).
gorre#uplink:~$ java -version
openjdk version "1.8.0_172"
OpenJDK Runtime Environment (build 1.8.0_172-02)
OpenJDK 64-Bit Server VM (build 25.172-b02, mixed mode)
gorre#uplink:~$ which java
/home/gorre/.nix-profile/bin/java
gorre#uplink:/nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02$ ll
total 24K
dr-xr-xr-x 3 gorre 4.0K Dec 31 1969 share/
dr-xr-xr-x 2 gorre 4.0K Dec 31 1969 nix-support/
dr-xr-xr-x 3 gorre 4.0K Dec 31 1969 lib/
lrwxrwxrwx 1 gorre 80 Dec 31 1969 jre -> /nix/store/n7rh8v269qb1fs6314yq0wg7q8cajw0g-openjdk-8u172b02-jre/lib/openjdk/jre/
dr-xr-xr-x 2 gorre 4.0K Dec 31 1969 include/
lrwxrwxrwx 1 gorre 76 Dec 31 1969 bin -> /nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02/lib/openjdk/bin/
Now when I try build/run a project that uses Gradle 4.4 within IntelliJ IDEA 2017.3.4 (Ultimate Edition) Build #IU-173.4548.28 I get this error:
The newly created daemon process has a different context than expected.
It won't be possible to reconnect to this daemon. Context mismatch:
Java home is different.
Wanted: DefaultDaemonContext[uid=null,javaHome=/nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02,daemonRegistryDir=/home/gorre/.gradle/daemon,pid=12824,idleTimeout=null,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]
Actual: DefaultDaemonContext[uid=b813ba02-e4a6-4bfe-91b2-8ed32963f7cc,javaHome=/nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02/lib/openjdk,daemonRegistryDir=/home/gorre/.gradle/daemon,pid=14245,idleTimeout=10800000,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]
I've searched here and there but the other answers/solutions don't work, not even specifying the Java home in gradle.properties (inside the project or in my user's home):
org.gradle.java.home = /nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02
On the other hand, if I build/run the project on a terminal it works fine. Any clues?
UPDATE #1
This is my configuration for Gradle and the SDK in IntelliJ IDEA:
Check Idea settings for Gradle daemon:
Build, Execution, Deployment -> Build Tools -> Gradle.
There is an option "Gradle JVM". Looks that Idea uses Java 9 or some other non-compatible JVM to run Gradle.
Yoy should select your Java version from Nix.
I figured this out, even though it was in front of my nose — I didn't read carefully the error message(s).
Basically, the default Java home set by Nix was at: /nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02/lib/openjdk and the one I manually set inside IntelliJ IDEA was at: /nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02 (notice the missing ../lib/openjdk segment).
After correcting that in IntelliJ IDEA everything worked fine. I didn't need anything additional and/or special.
I hope this helps someone else in the future — or any other fast-reader Nix'ers.
I have a strange behaviour while analysing my Java Code.
The analysis is done on a daily basis.
On the first run some issue are identified, so far so good.
After the next run there are issues marked as Fixed.
The Message i got in sonarQube:
Juli 2015 10:33 Uhr Created
Juli 2015 20:30 Uhr Resolution changed to FIXED
Status changed to CLOSED (was OPEN)
But there was no change at this File between the two runs.....
Java: JDK 1.8.0_u45
SonarQube: 5.1.1
Any Idea???
Thanks in advance
Kai