We have a large Hudson set up with many scheduled builds running all the time. Currently I'm trying to get one build to work properly, but I have to occasionally wait when a scheduled build enters the queue. Is there a way to disable all the scheduled builds so I can concentrate on my troublesome build, without adjusting the "cron" settings of each individual build?
Tell it to prepare to shut down.
Edit from OP (banjollity)
It's not perfect, but I think this is a reasonable "few mouse clicks solution with a default install" kind of solution, hence the accepted answer.
Queue up a job
Tell Hudson to prepare to shut down. This prevents other jobs being run in the meantime.
Diagnose faults with my job, commit new code that might fix it. (I love my job).
Cancel Hudson shut down.
Goto step 1.
The 'configuration slicing' plugin I contributed allows you to modify the cron settings of many jobs simultaneously. This should allow you to make the bulk changes you want.
Expanding upon Mikezx6r's suggestion, I just came up with a quick method to disable all builds matching a certain string:
[user#server jobs] $ for i in *build_name*; do sed -i s/"disabled>false"/"disabled>true/" $i/config.xml; done
You could also iterate through specific build names in the "for" loop:
[user#server jobs] $ for i in build1 build2 build3; do sed -i s/"disabled>false"/"disabled>true/" $i/config.xml; done
You can test it first to see what it will do by putting an "echo" before sed:
[user#server jobs] $ for i in build1 build2 build3; do echo sed -i s/"disabled>false"/"disabled>true/" $i/config.xml; done
Conversely, you can re-enable all matching jobs by switching around the sed script:
[user#server jobs] $ for i in build1 build2 build3; do sed -i s/"disabled>true"/"disabled>false/" $i/config.xml; done
I don't see a direct way to do it, but you could write something that updates the config.xml for all jobs.
In each job's directory in hudson, there's a config.xml. The <project> has an element called disabled that you could update to true, thereby disabling that build.
Not ideal, but once you have the script to walk a directory and change the value of disabled, you can always use it.
A search for something similar brought me to this question, and I realized there's another benefit of Michael Donohue's answer (and the plugin he contributed).
With "Configuration Slicing," it's easy to disable a subset of your jobs all at once. That's exactly what I needed to temporarily disable 7 of 8 related jobs so I could work on the 8th. Thanks Michael!
This can be done using jenkins Console. It runs groovy script and do almost anything.
Following script iterates through all projects. Check if it has TimerTrigger.(One can extend this check of other triggers as well)
import hudson.model.Hudson
import hudson.model.Project
import hudson.triggers.TimerTrigger
import hudson.triggers.Trigger
import hudson.triggers.TriggerDescriptor
//All the projects on which we can apply the getBuilders method
def allProjects = Hudson.instance.items.findAll { it instanceof Project }
def projectsToWorkOn = [];
allProjects.each { Project project ->
Map<TriggerDescriptor, Trigger> triggers =
project.getTriggers();
triggers.each { trigger ->
if (trigger.value instanceof TimerTrigger) {
projectsToWorkOn.push(project)
}
}
}
projectsToWorkOn
.each { Project project ->
project.disable();
project.save()
}
Related
I'm writing an IntelliJ plugin, and attempting to integrate JxBrowser into the plugin's tool window via Java Swing.
I'm using the toolWindow extension to keep the tool window integration simple.
plugin.xml
<extensions defaultExtensionNs="com.intellij">
<toolWindow id="pluginid" anchor="right" factoryClass="com.solutionloft.codeclippy.MainWindowFactory" />
</extensions>
And so my main factory class looks like this:
public class MainWindowFactory implements ToolWindowFactory {
#Override
public void createToolWindowContent(#NotNull Project project, #NotNull ToolWindow toolWindow) {
Browser browser = new Browser();
BrowserView view = new BrowserView(browser);
Content content = toolWindow.getContentManager().getFactory().createContent(view, "", false);
toolWindow.getContentManager().addContent(content);
browser.loadHTML("<html><body><h1>Hello World!</h1></body></html>");
}
}
This appears to work when I run the plugin locally initially (the tool window comes up, and I can see Hello World), but if I terminate the process and then try to run it again, I run into this error:
Received signal 10 BUS_ADRERR 000103bc3000
[0x00017cd9540c]
[0x00017cd95301]
[0x7fff572eef5a]
[0x7fbe7e9f5000]
[end of stack trace]
Process finished with exit code 138 (interrupted by signal 10: SIGBUS)
Am I missing some kind of cleanup step? I'm not sure what could still be running - the only workaround I've found at this point is to do a full computer restart, so I guess some process must be still running that's causing it to conflict. What's the proper way to clean up? Does it have anything to do with browser.dispose()? I haven't had much luck finding documentation on when .dispose() would be appropriate / if it's needed.
I'm using:
* macOS High Sierra
* Java 1.8.0_151 as my JDK
* PyCharm Ultimate as my JRE
Thanks!
Update: Noticed if I kill this process /System/Library/Frameworks/LocalAuthentication.framework/Support/coreauthd, the problem goes away for the next few runs. But sometimes this process doesn't exist and killing a still-running java process is the fix... odd.
According to TeamDev support, the solution is to set the system property jxbrowser.ipc.external=true. Calling System.setProperty("jxbrowser.ipc.external", "true") before you create your browser instance should do the trick. The catch is that the JxBrowser will run in lightweight mode.
You may also ensure that you're properly disposing all browser instances via browser.dispose() and the Chromium engine via BrowserCore.shutdown().
According to the article, all browser instances should disposed when you don't need them. Please try disposing all browser instances before closing your application.
This question is related to a previous question, here: Java Runtime.getRuntime().exec() appears to be overwriting $PATH
I am trying to build Go from source from inside a Java program. I can build it properly using Terminal, but Java's Runtime.getRuntime().exec() gets interesting results. I tried using ProcessBuilder, but could not get it to properly make Go. Using my current setup with exec(), it makes properly, but then fails two tests. Code snippet:
String[] envp = new String[4];
envp[0] = "CC=/usr/bin/clang";
envp[1] = "GOROOT_BOOTSTRAP=/usr/local/go";
envp[2] = "CGO_ENABLED=0";
envp[3] = "PATH=" + System.getenv().get("PATH");
Runtime.getRuntime().exec("./all.bash", envp, "$HOME/Desktop/go/src");
It runs properly and compiles properly, but when it gets to running the test suite, I get two errors:
--- FAIL: TestCurrent (0.00s)
user_test.go:24: Current: user: Current not implemented on darwin/amd64 (got &user.User{Uid:"502", Gid:"20", Username:"", Name:"", HomeDir:""})
FAIL
FAIL os/user 0.009s
and a much longer one that I won't paste here due to absurd length, but it comes down to:
panic: test timed out after 3m0s
...
FAIL runtime 180.056s
I haven't any idea why the former is failing, but for the runtime when I build from the Terminal, it says:
ok runtime 19.096s
So something is causing that to take absurd amounts of time. I did some googling, and heard that it might be fixed if I use ARM=5 as an environment variable, but that didn't change anything. Does anyone have any idea why these tests are failing when I build from Java as opposed to the Terminal?
Looking at the source code for the os/user package, it looks like the native user handling depends on having cgo enabled. If cgo=0 (your case), it will fall back to the USER and HOME environment variables.
source code in question
Try putting USER=whatever in your exec environment.
I'm afraid I'd need more information to diagnose the runtime issue.
I have two .jar files that I want to call from a Python script. However, after I call the first jar, the terminal sits and doesn't process anything after that point as the server is running. The server starts fine, but I want to start another process that will run until I ask them to stop.
I've had trouble searching for possible solutions because I'm unsure of what terminology to use.
from subprocess import call
import glob
import sys
h2 = glob.glob("h2*.jar")
reasoner = glob.glob("reasoner*.jar")
h2 = h2.pop()
reasoner = reasoner.pop()
call(["java", "-jar", h2, "-tcp"]) # Any call commands after this point don't execute
Use subprocess.Popen instead of subprocess.call which wait the sub-process to terminate.
from subprocess import Popen
...
Popen(["java", "-jar", h2, "-tcp"])
FYI, Python documentation is good place to look, especially subprocess module documentation for this specific problem.
UPDATE
If you want to wait the sub-process explicitly when you're using Popen, save the reference to the Popen object and use wait method:
proc = Popen(["java", "-jar", h2, "-tcp"])
# Do something else ..
proc.wait() # block execution until the sub-process terminate.
I am using Java in Play framework and I have some tests (functional tests) that are passed when I run them through my IDE (IntelliJ) but failed when I run the tests through console.
My problems is that the stack traces that are shown in the test logs are only 2 lines and I need the complete stack trace to see what is going on in there, I have tried any combination of settings mentioned here: spec2 settings both through putting them in build.sbt or providing them in the command line. It seems that there is no effect! Here is my build.sbt:
version := "1.0-SNAPSHOT"
libraryDependencies ++= Seq(
javaJdbc,
javaEbean,
cache,
filters
)
logBuffered in Test := false
testOptions += Tests.Argument(TestFrameworks.JUnit, "-v")
testOptions += Tests.Argument("fullStackTrace","true")
traceLevel := 50
Can someone help me please? I am using Typesafe activator (play 2.2.2). Thanks
In Play 2.3.2 this can be acheieved using the -a option in build.sbt:
testOptions += Tests.Argument(TestFrameworks.JUnit, "-a")
I use:
testOptions += Tests.Argument(TestFrameworks.JUnit, "-v", "-q", "-a")
as this provides test started/finished messages (-v) and suppresses logging for passed tests (-q).
All of the available options can be found in the SBT JUnit Interface:
-v Log "test run started" / "test started" / "test run finished" events on log level "info" instead of "debug".
-q Suppress stdout for successful tests. Stderr is printed to the console normally. Stdout is written to a buffer and discarded when a test succeeds. If it fails, the buffer is dumped to the console. Since stdio redirection in Java is a bad kludge (System.setOut() changes the static final field System.out through native code) this may not work for all scenarios. Scala has its own console with a sane redirection feature. If Scala is detected on the class path, junit-interface tries to reroute scala.Console's stdout, too.
-n Do not use ANSI colors in the output even if sbt reports that they are supported.
-s Try to decode Scala names in stack traces and test names. Fall back silently to non-decoded names if no matching Scala library is on the class path.
-a Show stack traces and exception class name for AssertionErrors (thrown by all assert* methods in JUnit). Without this option, failed assertions do not print a stack trace or the "java.lang.AssertionError: " prefix.
-c Do not print the exception class name prefix for any messages. With this option, only the result of getMessage() plus a stack trace is shown.
+v Turn off -v. Takes precedence over -v.
+q Turn off -q. Takes precedence over -q.
+n Turn off -n. Takes precedence over -n.
+s Turn off -s. Takes precedence over -s.
+a Turn off -a. Takes precedence over -a.
+c Turn off -c. Takes precedence over -c.
--ignore-runners=<COMMA-SEPARATED-STRINGS> Ignore tests with a #RunWith annotation if the Runner class name is contained in this list. The default value is org.junit.runners.Suite.
--tests=<REGEXPS> Run only the tests whose names match one of the specified regular expressions (in a comma-separated list). Non-matched tests are ignored. Only individual test case names are matched, not test classes. Example: For test MyClassTest.testBasic() only "testBasic" is matched. Use sbt's test-only command instead to match test classes.
-Dkey=value Temporarily set a system property for the duration of the test run. The property is restored to its previous value after the test has ended. Note that system properties are global to the entire JVM and they can be modified in a non-transactional way, so you should run tests serially and not perform any other tasks in parallel which depend on the modified property.
--run-listener=<CLASS_NAME> A (user defined) class which extends org.junit.runner.notification.RunListener. An instance of this class is created and added to the JUnit Runner, so that it will receive the run events. For more information, see RunListener. Note: this uses the test-classloader, so the class needs to be defined in src/test or src/main or included as a test or compile dependency
--include-categories=<CLASSES> A comma separated list of category class names that should be included. Only tests with one or more of these categories will be run.
--exclude-categories=<CLASSES> A comma separated list of category class names that should be excluded. No tests that match one or more of these categories will be run.
Play 2.2.3 was just released. Includes a fix for bug 2535, which I think might be the issue you're seeing.
https://groups.google.com/forum/#!topic/play-framework/KP1_DbhcxlU
I am new to plugin development for IntelliJ and would like to know, how I can execute a command in the command line from within my plugin.
I would like to call, for instance, the command "gulp" in the current projects root directory.
I already tried using
Runtime.getRuntime().exec(commands);
with commands like "cd C:\Users\User\MyProject" and "gulp", but it does not seem to work that way and I wonder, if the plugin API provides an easier method.
I know its a bit late (1 year later), but recently I was working on an IntelliJ plugin and I had the same issue and this is what I used and it works pretty well.
First, we need to create a list of commands that we need to execute:
ArrayList<String> cmds = new ArrayList<>();
cmds.add("./gradlew");
Then
GeneralCommandLine generalCommandLine = new GeneralCommandLine(cmds);
generalCommandLine.setCharset(Charset.forName("UTF-8"));
generalCommandLine.setWorkDirectory(project.getBasePath());
ProcessHandler processHandler = new OSProcessHandler(generalCommandLine);
processHandler.startNotify();
hence the generalCommandLine.setWorkDirectory is set to the project directory which could be equivalent to the terminal command cd path/to/dir/
The Runtime class provides exec(String[], String[], File) method where the last argument is working directory of the subprocess being launched.
The plugin API provides OSProcessHandler class (as well as other classes like ProcessAdapter) which can help to manage the subprocess, handle its output etc.
ProcessOutput result1 = ExecUtil.execAndGetOutput(generalCommandLine);
result1.getStdOut result1.getStdErr works
and
ScriptRunnerUtil.getProcessOutput(generalCommandLine, ScriptRunnerUtil.STDOUT_OUTPUT_KEY_FILTER, timeout);
both work pretty well
and they are built into intellij
import com.intellij.execution.process.ScriptRunnerUtil;
import com.intellij.execution.util.ExecUtil;