I'd like to call a batch-script during a cvs tag operation on a cvsnt server. But everyting I get is "script execution failed". Where is the script I'd like to call supposed to be located or how could I address it with variables?
If I call shell commands directly like "echo something" everything works fine and I also get the additional parameters added by cvsnt like the actual TAG, command and directory. If I want to call a batch either with relative path, without a past or even with ${CVSROOT}/CVSROOT/triggerbuild.cmd everything I get is 'script execution failed'.
My taginfo entries:
ALL echo
-> results in tag command folder
ALL echo ${CVSROOT}/CVSROOT/trigger_release_build.bat
-> results in 'script execution failed'.
I want to simply call a batch script that trigger my jenkins server to start a build under some conditions. The trigger script is finished and working fine when executed from a local shell. Only integratino in cvsnt taginfo file doesn't work.
addition: the quoted Code is the overall code causing the failure. The code of the batch file is not relevant because it is not even called due to the error.
This is the documentation from cvsnt's tagfile:
# The "taginfo" file is used to control pre-tag checks.
# The filter on the right is invoked with the following arguments:
#
# $1 -- tagname
# $2 -- operation "add" for tag, "mov" for tag -F, and "del" for tag -d
# $3 -- repository
#
# The filter is passed a series of filename/version pairs on its standard input
#
# A non-zero exit of the filter program will cause the tag to be aborted.
#
# The first entry on a line is a regular expression which is tested
# against the directory that the change is being committed to, relative
# to the $CVSROOT. For the first match that is found, then the remainder
# of the line is the name of the filter to run.
#
# If the repository name does not match any of the regular expressions in this
# file, the "DEFAULT" line is used, if it is specified.
#
# If the name "ALL" appears as a regular expression it is always used
# in addition to the first matching regex or "DEFAULT".
When using backslashes I get different error messages about invalid characters \C
Related
An open source project I'm working on has components that require Linux and consequently virtualization has generally been the best solution for development and testing new features. I'm attempting to provide a simple cloud-init file for Multipass that will configure the VM with our code by pulling our files from Git and setting them up in the VM automatically. However, even though extra time elapsed for launch seems to indicate the process is being run, no files seem to actually be saved to the home directory, even for simpler cases, i.e.
runcmd:
- [ cd, ~ ]
- [ touch test ]
- [ echo 'test' > test ]
Am I just misconfiguring cloud-init or am I missing something crucial?
There are a couple of problems going on here.
First, your cloud config user data must begin with the line:
#cloud-config
Without that line, cloud-init doesn't know what to do with it. If you were to submit a user-data configuration like this:
#cloud-config
runcmd:
- [ cd, ~ ]
- [ touch test ]
- [ echo 'test' > test ]
You would find the following errors in /var/log/cloud-init-output.log:
runcmd.0: ['cd', None] is not valid under any of the given schemas
/var/lib/cloud/instance/scripts/runcmd: 2: cd: can't cd to None
/var/lib/cloud/instance/scripts/runcmd: 3: touch test: not found
/var/lib/cloud/instance/scripts/runcmd: 4: echo 'test' > test: not found
You'll find the solution to these problems in the documentation, which includes this note about runcmd:
# run commands
# default: none
# runcmd contains a list of either lists or a string
# each item will be executed in order at rc.local like level with
# output to the console
# - runcmd only runs during the first boot
# - if the item is a list, the items will be properly executed as if
# passed to execve(3) (with the first arg as the command).
# - if the item is a string, it will be simply written to the file and
# will be interpreted by 'sh'
You passed a list of lists, so the behavior is governed by "*if the item is a list, the items will be properly executed as if passed to execve(3) (with the first arg as the command)". In this case, the ~ in [cd, ~] doesn't make any sense -- the command isn't being executed by the shell, so there's nothing to expand ~.
The second two commands include on a single list item, and there is no command on your system named either touch test or echo 'test' > test.
The simplest solution here is to simply pass in a list of strings intead:
#cloud-config
runcmd:
- cd /root
- touch test
- echo 'test' > test
I've replaced cd ~ here with cd /root, because it seems better to be explicit (and you know these commands are running as root anyway).
I'm currently using unison for syncing local files with my cloud. Therefore I have set up a batch file which contains all options I need.
"K:\unison\unison 2.48.4 text.exe" -batch -repeat 1200 -fastcheck true -log=false D:\localsync Z:\cloudsync
In order to tell unison to skip all folders with the name ".tmp" regardless of their path I came up with this command:
"K:\unison\unison 2.48.4 text.exe" -batch -repeat 1200 -fastcheck true -log=false -ignore=Name{*.*.tmp} D:\localsync Z:\cloudsync
The *.*.tmp construct is recommend since unison ignores all names beginning with a dot.
Unfortunately, unison throws an error here when I run the batch file:
Uncaught exception Sys_error("C:\Users\name\.unison\*.tmp)
It then complains that the syntax for the directory name is wrong. Obviously, unison is reading the ignore statement and looking for a file with the name of the to be ignored folder in the .unison directory.
I couldn't come up with a solution to that. All information in the manual (https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html) sets ignore paths in the unison profile which I'm not using.
How's the way to get unison to ignore some directories when only using command line options?
I think your syntax is wrong. Try
-ignore 'Name {*.*.tmp}'
From the Unison manual
Ignore patterns can also be specified on the command line, if you like (this is probably not very useful), using an option like -ignore 'Name temp.txt'.
I have a bash script with the following functionality:
# usage: setOutput <name> <value>
function setOutput {
echo "##vso[task.setvariable variable=$1]$2"
}
setOutput environment "dev"
This normally sets the variable correctly as ENVIRONMENT=dev - however, sometimes this randomly appends a ' at the end, i.e. ENVIRONMENT=dev'
I tried re-running the same commit on the pipeline multiple times, and sometimes it works, sometimes it doesn't. Any ideas?
I tested it with your sample, it can be displayed normally .
You can try to remove the double quotes of dev to see if this will happen.
function setOutput {
echo "##vso[task.setvariable variable=$1]$2"
}
setOutput environment dev
Base on the fact that #Hugh Lin - MSFT could not reproduce the issue, I looked a littel closer and found out, what was actually going wrong:
In the beginning of my script, I used:
set -ex
This lead to there beeing two echos:
+echo '##vso[task.setvariable variable=key]value'
##vso[task.setvariable variable=key]value
Depending on the order of the two (since the first is written to stderr, the second one to stdout), sometimes the value was set to the correct value, and somtimes to the debug echo one. And since that one has the addition ' at the end, so does the exported output.
My suggestion: Only process stdout for these echo commands, not stderr, or add a special filter for set -x. I removed the debug output and now it works.
I have a python script that I would like to run using rundeck that is invoked as follows:
createInstance.py [-n <name>] <env> <version>
Where name is optional and env and version are required.
e.g. if I want to call the script with a name I would call:
createInstance.py -n test staging 1.2.3.4
If I want to default the name, I would call:
createInstance.py staging 1.2.3.4
The problem i have is that I dont know how to specify the script arguments string in rundeck. I have a job, with 3 options, one for env, version and name and if I define the arguments string as:
-n ${option.name} ${option.env} ${option.version}
Whenever the name is unset, rundeck calls:
createInstance.py -n staging 1.2.3.4
Instead I would like it to omit the -n. Is there any way of doing this? Right now my only option is to change the script to be more forgiving in how it handles the -n, and to always ensure its at the end, e.g.:
createInstance.py staging 1.2.3.4 -n
createInstance.py staging 1.2.3.4 -n test
I would like to avoid making this change though, as I want to be able to use the scripts standalone as well.
Rather than use a command step, try an inline script step. Your inline script can count the number of arguments and if they are set. Then with that logic you can choose how to set the creteInstance.py args.
As #Alex-SF suggests, I've also used an inline script for this, along with a Key Value Data log filter. The script is:
#!/bin/bash
# Parse optional parameters
# https://stackoverflow.com/questions/41233996/passing-optional-parameters-to-rundeck-script
# Arguments to this script should be in the format "flag" "value", eg "-p" ${option.name}
# If value is not missing then return will be "flag value", otherwise blank
echo -n "RUNDECK:DATA:"
while (( "$#" )); do
flag="$1"
value="$2"
if [[ -z "$value" ]] || [[ $value =~ ^\- ]]; then
# no value for this parameter (empty or picking up the next flag)
echo -n ""
shift
else
# value provided for this parameter
echo -n "$flag $value "
shift
shift
fi
done
And the key value data filter uses the pattern ^RUNDECK:DATA:(.*)$ and the name data args. Then I use ${data.args*} as the input for the real command.
It's all rather messy, and I can't find any open issue requesting this as a feature (yet).
Use an inline script and use conditional variable expansion feature from bash.
createInstance.py ${RD_OPTION_NAME:+-n $RD_OPTION_NAME} $RD_OPTION_ENV $RD_OPTION_VERSION
This will omit the first option altogether if it is empty ("").
Running Windows 7, configuring a commit hook in my .hgrc file.
The hook calls an external powershell script and passes it a few parameters. When I put all the parameters on one long line, the script receives them just fine. However, when I try to put each parameter on its own line, the hook can't figure out that they are all part of the same call to my external script.
[hooks]
commit.working_one_liner = PowerShell.exe -ExecutionPolicy Bypass -File .\MyScript.ps1 -hg %HG% -updatedToChangeset %HG_NODE% -dbName 'Test'
commit.multi_line_hook_not_working = PowerShell.exe
-ExecutionPolicy Bypass
-File .\MyScript.ps1
-hg %HG%
-updatedToChangeset %HG_NODE%
-dbName 'Test'
According to the Hg documentation, I should be able to do this:
"A configuration file consists of sections, led by a [section] header and followed by name = value entries (sometimes called configuration keys):
[spam]
eggs=ham
green=
eggs
Each line contains one entry. If the lines that follow are indented, they are treated as continuations of that entry. Leading whitespace is removed from values. Empty lines are skipped. Lines beginning with # or ; are ignored and may be used to provide comments."
Despite indenting, the multi_line_hook seems to ignore everything after the first line. I've tried various escape characters (`, ^, \, etc.) after each new line. Any ideas what I'm missing here?
The example from the documentation only works for the first line to follow and not the rest.
I don't have access to windows at the moment, but on linux I need to use a backslash:
[hooks]
commit.working = echo \
test