I just started using Git with the TortoiseGit 2.8.0.0 client on Windows 10 and was trying to set up some client-side hooks. I would like to set them up in a way so that they are automatically set when I or my colleagues clone the repo so I checked "Run for this repository".
I noticed that the Start-commit Hook isn't being executed in that case. Pre-commit and Post-commit seem to work as expected.
If I provide the working tree path and don't check "Run for this repository" all scripts also run as expected.
For testing I just set the same script for all 3 hooks to see if they are working.
My .tgitconfig looks like this:
[hook "startcommit"]
cmdline = %root%\\ARM\\start_commit.bat
wait = true
show = false
[hook "postcommit"]
cmdline = %root%\\ARM\\start_commit.bat
wait = true
show = false
[hook "precommit"]
cmdline = %root%\\ARM\\start_commit.bat
wait = true
show = false
Can anyone explain this behaviour and how to fix it? am I missing something here?
That's a reproducible bug which will be fixed with the next (preview) release (version >= 2.8.4 are fixed).
There is no workaround, but to define it with a repository path, too.
Related
I run web projects like this, during development:
dotnet watch run
The project/browser reloads when I make a change. Awesome!
However, sometimes I will be shown this:
Unable to apply hot reload because of a rude edit.
Do you want to restart your app - Yes (y) / No (n) / Always (a) / Never (v)?
Is there something I can add to the commandline, so I force the Always (a) option?
Something like this:
dotnet watch run --AlwaysRestartOnRudeEdit
According to my google-fu/duckduck-fu, such an option does not exist - but I would like it confirmed. :)
Not yet. A feature like that has been merged into the .NET 6.0.2 update. Once released, it will be possible to force this behavior by setting an environment variable named DOTNET_WATCH_RESTART_ON_RUDE_EDIT to true.
Source: aspnetcore issue #37190
Until then, user eknkc posted a possible workaround (Unix):
#!/usr/bin/env expect -f
set timeout -1
spawn dotnet watch run
expect "Do you want to restart your app - Yes (y) / No (n) / Always (a) / Never (v)?\r"
send -- "a"
expect eof
Create an environment variable DOTNET_WATCH_RESTART_ON_RUDE_EDIT set to true. The run dotnet watch like normal.
I have added a new test target in xcode. I want to test my unit test cases by running it as root since it involves creation of certain directories where root has permissions. But I find that it is disabled to select the process to run as root.Any help on how to test it with root permissions ?
I had this problem and managed to fix it by manually editing the corresponding *.xcscheme file.
Assuming you have the "Run" configuration set up to do this, you will see the following in the *.xcscheme file:
<LaunchAction
...
debugAsWhichUser = "root"
...>
...
</LaunchAction>
Simply add the property manually to the TestAction section as well:
<TestAction
...
debugAsWhichUser = "root"
...>
...
</TestAction>
After making this change, I simply restarted XCode, and now the disabled radio buttons show the correct value as seen here:
Correct settings
Running verified for me that it all worked!
* I should mention that this was on Version 8.1 (8B62), I have no reason to think this should vary by version but YMMV.
After a few mistake builds with the Release configuration pushing stuff to other environments I'd like to have a warning or prompt of some sort to stop me from doing such madness if I don't really want to.
Is there a way to make this happen? :)
The simplest way that I can see of doing this is to leverage the Build Events dialog in the Project Settings.
First add a file called usermessage.vbs to the solution. It should contain the following:
a = MsgBox("Continue with Debug Build",1,"Build Configuration Warning")
if a=1 then WScript.Quit(0) Else WScript.Quit(1) End If
This will present an OK/Cancel dialog which returns an error unless you click OK.
Add this code to the Pre-build event command line:
if $(ConfigurationName) == Debug WSCRIPT.EXE "$(SolutionDir)usermessage.vbs"
This will run the script if you build in debug configuration.
The script will error and the build will halt unless you click OK in the dialog.
I'm using Scriptler plugin, so I can run a groovy script as a build step. My Jenkins slaves are running on windows in service mode. With scriptler, I don't need to use windows batch scripts.
But I have trouble to get the environment variables in a build step... This is working:
System.getenv("BASE")
Where BASE is part of the env-vars on jenkins startup. However, I would like to get
%JOB_NAME%
If I'm adding an "Execute Windows batch command" build step:
echo %JOB_NAME%
It works.
If I'm adding a scriptler script as a build step with the same settings:
println "JOB_NAME: " + System.getenv("JOB_NAME")
I'm getting:
JOB_NAME: null
So how can I reach the injected environment variables from a groovy script as a build step?
build and listener objects are presenting during system groovy execution. You can do this:
def myVar = build.getEnvironment(listener).get('myVar')
You might be able to get them like this:
def thr = Thread.currentThread()
def build = thr?.executable
def envVarsMap = build.parent.builds[0].properties.get("envVars")
On jenkins 2.x, with groovy plugin 2.0, running SystemGroovyScript I managed to get to build variables, as below:
def build = this.getProperty('binding').getVariable('build')
def listener = this.getProperty('binding').getVariable('listener')
def env = build.getEnvironment(listener)
println env.MY_VARIABLE
If you are using goovy from file, simple System.getenv('MY_VARIABLE') is sufficient
The Scriptler Groovy script doesn't seem to get all the environment variables of the build. But what you can do is force them in as parameters to the script:
When you add the Scriptler build step into your job, select the option "Define script parameters"
Add a parameter for each environment variable you want to pass in. For example "Name: JOB_NAME", "Value: $JOB_NAME". The value will get expanded from the Jenkins build environment using '$envName' type variables, most fields in the job configuration settings support this sort of expansion from my experience.
In your script, you should have a variable with the same name as the parameter, so you can access the parameters with something like:
println "JOB_NAME = $JOB_NAME"
I haven't used Sciptler myself apart from some experimentation, but your question posed an interesting problem. I hope this helps!
The only way I could get this to work (on Linux) was to follow this advice:
https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+System+Groovy+script
import hudson.model.*
// get current thread / Executor and current build
def thr = Thread.currentThread()
def build = thr?.executable
// if you want the parameter by name ...
def hardcoded_param = "FOOBAR"
def resolver = build.buildVariableResolver
def hardcoded_param_value = resolver.resolve(hardcoded_param)
println "param ${hardcoded_param} value : ${hardcoded_param_value}"
This is on Jenkins 1.624 running on CentOS 6.7
Jenkins 2.x has the global variables. env is one of them from any script...
println env.JOB_NAME
More at https://build.intuit.com/services-config/pipeline-syntax/globals#env
One thing to note, if you are using a freestyle job, you won't be able to access build parameters or the Jenkins JVM's environment UNLESS you are using System Groovy Script build steps. I spent hours googling and researching before gathering enough clues to figure that out.
In System Groovy Script (Jenkins 2.89), I was able to use the environmental variable to disable another Jenkins job
import jenkins.*
import jenkins.model.*
def env = binding.build.environment
Jenkins.instance.getItemByFullName(env.job_name).setDisabled(false)
I also added a conditional step so as to either enable or disable another Jenkins job.
Thanks #Allan Lewis, your comment was helpful.
I was trying to resolve this issue, and searching forums etc. and trying for myself, without success.
We have a jenkins job and there we use the Release Plugin (with a standard configuration)
In the job then we have the "Perform Maven Release" in the left side to generate a version (tag, change poms, etc.) This work perfect.
We want to send an email to the team when the release has been done.
I tried the enviroment variable that the release plugin sets (IS_M2RELEASEBUILD by default) and combine with the email-ext plugin plugin where I can attach a groovy script (advanced=>trigger=>script trigger)
And I tried a lot of scripts to active the email, and none works, my last chance was:
def env = System.getenv()
env['IS_M2RELEASEBUILD'] == 'true'
but when I perform the release we have not the email sent (so this script evaluate the conditional to false or whatever)
Anyone has this setup in his Jenkins?
Thanks a lot!
You need to use "Editable Email Notification" as "Post-build Action" and paste
def env = build.getEnvironment();
String isRelease = env['IS_M2RELEASEBUILD'];
logger.println "IS_M2RELEASEBUILD="+isRelease;
if ( isRelease == null || isRelease.equals('false')) {
logger.println "cancel=true;";
cancel=true;
}
as Pre-send Script, fill in your E-Mail(s) in "Project Recipient List" and add an "Success"-Trigger.
(precondition is you have not changed the default "Release envrionment variable" in "Maven release build")
https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
This plugin allows you to configure every aspect of email notifications. You can customize when an email is sent, who should receive it, and what the email says.
This is not an answer, just a suggestion (I can't add comments). Have you tried echoing that environment variable in a post-build and pre-build step?
Have you tried having another build run when the release build completes successfully and have that job send the email, perhaps by running a shell script.