I am preparing and docker image based on jenkins:lts. To setup the initial configuration I use the init.groovy.d scripts, but:
is that the best option?
is there a way to prevent those scripts to run again in the second start? (I do not want to overwrite any change after init)
I end up using a file as a status marker
// Skip exec. if the init already run once, do not overwrite ui config
final File status = new
File("${System.getenv("JENKINS_HOME")}/init.groovy.d/uk-config.status")
if (status.exists()) {
logger.info("First init already run")
return
}
status.createNewFile()
It creates a file the first time the script runs and it checks if the file exists and prevent execution the second one.
Related
I need to run Moho lua script which created new document, import some files etc., by command line.
The problem is: to call this function requered ScriptInterface instance. It may called by mouse clicking, by menu selection in Moho ui (hand made calling) and sending ScriptingInterface instance as function parameter, like script:Run(moho). If I trying to call this function from commandline this instance not set as parameter.
So the question is - can I take ScriptInterface instance from some global vars or from somewhere else ??
You can prepare a special .moho file, which includes a layer with embed lua script. If you run command line opening Moho with this special file in it, it will execute the layer script (because it is executed on every new frame enter) and script will receive ScriptInterface instance as moho argument given to its LayerScript function.
After system restart where Jenkins is stored, one of the jobs is constantly failing it is trying to create bulid with number 1 but there is already 1400 past builds. Is there a way to change it so the build will be created with correct increment so in this case 1401.
Full stactrace from jenkins:
java.lang.IllegalStateException: [Directory]\builds\1 already existed; will
not overwite with [Build.Name] #1
at hudson.model.RunMap.put(RunMap.java:189)
at jenkins.model.lazy.LazyBuildMixIn.newBuild(LazyBuildMixIn.java:178)
at hudson.model.AbstractProject.newBuild(AbstractProject.java:1011)
at hudson.model.AbstractProject.createExecutable(AbstractProject.java:1210)
at hudson.model.AbstractProject.createExecutable(AbstractProject.java:144)
at hudson.model.Executor$1.call(Executor.java:328)
at hudson.model.Executor$1.call(Executor.java:310)
at hudson.model.Queue._withLock(Queue.java:1251)
at hudson.model.Queue.withLock(Queue.java:1189)
at hudson.model.Executor.run(Executor.java:310)
You can use a groovy script in $JENKINS_URL/script as follows:
item = Jenkins.instance.getItemByFullName("jobName")
item.updateNextBuildNumber(1401)
It looks like you can use the "Next Build Number" plugin to accomplish this: https://wiki.jenkins.io/display/JENKINS/Next+Build+Number+Plugin
There is a file you can edit: $JENKINS_HOME/jobs/../nextBuildNumber
$ cat /var/lib/jenkins/jobs/my-project/branches/develop/nextBuildNumber
42
You will need to reload configuration after changing it.
Is it possible to trigger a build with Files Found Trigger Plugin when multiple files are found in a certain directory?
For example:
The setting above is what I configured with Files Found Trigger.
The build is triggered when any one of the files (e.g. a.txt or b.txt) I specified exists. This is not the case I want.
How can I trigger the build only when both a.txt and b.txt exist?
This does not seem possible, when looking at how the search is performed in hudson.plugins.filesfoundtrigger.FileSearch#perform()
if (found.length == 1) {
formValidation = FormValidation.ok(Messages.SingleFileFound(found[0]));
} else {
formValidation = FormValidation.ok(Messages.MultipleFilesFound(Integer
.valueOf(found.length)));
}
You would need to setup a separate job which would create an ac.txt file if it detects both a.txt and b.txt, and would delete ac.txt otherwise.
That way, your current job can be triggered by a single file: ac.txt
I modified the source code of Files Found Trigger Plugin.
Hers's the modified version:
Now the build is triggered only if the number of files found is greater than or equal to Number of files found to tigger.
But this modification makes some of the tests fail. I'll create a pull request once I fix this problem.
Here's the pull request.
I have two tasks,task_1 should compress png files and task_2 should not compress png files,so i want to add an parameter to control it.
project.ext.set("compressPngs", 1);
task taskCompressPngs(type:Exec){
commandLine "myshell.sh"
args compressPngs
}
task task_1(dependsOn:'taskCompressPngs'){}
task task_2(dependsOn:'taskCompressPngs'){}
gradle.taskGraph.whenReady { taskGraph ->
if (taskGraph.hasTask(task_1))
{
compressPngs=1
}
if (taskGraph.hasTask(task_2))
{
compressPngs=0
}
}
But when i run task_1 or task_2，in task 'taskCompressPngs', 'compressPngs' passed to my script 'myshell.sh' always be 1, why? how to solve it?
taskCompressPngs gets configured before the configuration value is changed. Conditional configuration is rarely a good solution. A better approach is to declare two Exec tasks.
As others have mentioned, it's probably best to take the advice of #PeterNiederwieser and use two separate tasks, but if you really don't think you can, here are a couple other options that should work.
1) Check Gradle startParameter
Configure your reusable task based on which task is passed to gradle on the command line.
task taskCompressPngs(type: Exec) {
def compressPngs = 1
if(gradle.startParameter.taskNames.toString().toLowerCase().contains("task_2")) compressPngs = 0
commandLine "myshell.sh $compressPngs".tokenize()
}
This gives you a variable to use (gradle.startParameter.taskNames) that is available at configuration-time.
Here we change compressPngs to 0 only if task_2 is specified on the command line when running gradle.
I.E. gradlew task_1 will run myshell.sh 1, but gradlew task_2 (or even gradlew task_1 task_2) will run myshell.sh 0.
This logic could also be applied to a project property outside of the taskCompressPngs task - if, for example, you wanted to change other tasks too.
Again, this only works if "task_2" is specified in the command used to run gradle.
2) Use DefaultExecAction instead of Exec task
Instead of using a task of type Exec, you could write a custom task and check the taskGraph in it.
task taskCompressPngs << {
def compressPngs = 1
if(gradle.taskGraph.hasTask(two)) compressPngs = 2
org.gradle.process.internal.DefaultExecAction e = new org.gradle.process.internal.DefaultExecAction(getServices().get(org.gradle.api.internal.file.FileResolver.class))
e.commandLine("myshell.sh $compressPngs".tokenize())
e.execute()
}
This is just moves your existing logic from configuration-time to execution-time.
This requires the use of "internal" Gradle classes (which is bad), but it gives you a little more flexibility in how/when the shell command is run.
Note that these solutions were checked against Gradle 1.7 and Gradle 1.11.
I created a simple Windows service in dot net which runs a file. When I run the service locally I see the file running in the task manager just fine. However, when I run the service on the server it won't run the file. I've checked the path to the file which is fine. Below is the code used to launch the process which runs the file. Any ideas?
protected override void OnStart(string[] args)
{
// TODO: Add code here to start your service.
eventLog1.WriteEntry("VirtualCameraService started");
// Create An instance of the Process class responsible for starting the newly process.
System.Diagnostics.Process process1 = new System.Diagnostics.Process();
// Set the directory where the file resides
process1.StartInfo.WorkingDirectory = "C:\\VirtualCameraServiceSetup\\";
// Set the filename name of the file to be opened
process1.StartInfo.FileName = "VirtualCameraServiceProject.avc";
// Start the process
process1.Start();
}
My first instinct is to check permissions.
Is the file extension registered on the server? It could be that the server is failing to find an action associated with .avc. You might want to move this to ServerFault since it is most likely a configuration or Windows OS version difference.
You may want to put a try catch block in that method and write out any exception to the event log, this should piont you in the write direction.
But as D.Shawley said it sounds like a config issue.
Ok, once again the problem was that the file wasn't associated to the program on the server. So instead of trying to open the file I needed to open the program to run the file, then pass the file as an argument to the program. Below is the syntax.
// Set the directory where the file resides
process1.StartInfo.WorkingDirectory = "C:\\Program Files (x86)\\Axis Communications\\AXIS Virtual Camera 3\\";
// Set the filename name of the file to be opened
//process1.StartInfo.FileName = "VirtualCamera.exe C:\\VirtualCameraServiceSetup\\VirtualCameraServiceProject.avc";
process1.StartInfo.FileName = "VirtualCamera.exe";
process1.StartInfo.Arguments = "VirtualCameraServiceProject.avc";