I am trying to send a property to a build configuration through a command line invocation of sendchange.
Here is a snippet of my master.cfg
factory = util.BuildFactory()
factory.addStep(
steps.ShellCommand(
command=["echo", util.Property('grid', default=2)]))
I am invoking the build using this command
buildbot sendchange --master my-server:9989 --auth me:mypass --who slineisitanyway --branch=master --property grid:5 a.txt
When I check the shell output in the web UI, I see that, indeed, the build did run, it succeeded, and it chose the default of 2, even though I have specified the property 'grid' on the command line.
Anyone know what I'm doing wrong?
You didn't specify revision. In this case Buildbot uses property from cache ;) I faced just same issue during testing.
Related
I'm just getting started with rundeck and trying to find out how it works.
I created a simple Job that should install some packages on the remote note from a pre-selected list (Option).
When I select more than one option the command fails. I want to find out why it fails but (even with debug-mode enabled) see nowhere which command is actally being executed on the remote node.
My command looks like yum install -y "${option.package}" and the unexpected response is eg: no package [selected options] available ... I have selected (space) as delimitter.
How can I see what is executed on the remote host?
Update:
I meanwhile found out why my options did not work as expected; I had to use the unqouted variant for the command-line. But the main question still stays the same ...
Right now the only way to see the exact executed command is to run the job on debug mode. Just select "Run with Debug output" and you can see the command dispatched in the middle of the execution output.
I have curl that i use in gitlab-ci job to upload an artifact to Nexus
the command is as follow (defined in .gitlab-ci.yml under script section)
cmd /c curl -v -u $env:USERREG:$env:PASSREG --upload-file $env:BINFILE $env:NEXUS_REGISTRY/$env:REPONAME$env:BINFILE
of course all the variables are declared in .gitlab-ci.yml file except for USERREG and PASSREG which i declared them using the gitlab GUI.
Notice that i am using:
- Gitlab Runner with docker-windows executor
- Windows docker container to exec the above command
PROBLEM : the job is stacked demanding for the user (defined by USERREG) password (PASSREG) until the job is terminated due to timeout.
How to fix this problem ? thank you.
I am not sure if this could be your problem, but please check and refer to the GitLab Variables which you set ( USERREG and PASSREG). If they are protected variables that means that they will be only available on a "protected" branches and in case you are pushing it from non-protected branch that could brings you to the state where you are currently because above mentioned variables are not available.
If this is the case, just make them to not be protected but masked and you should be fine.
I want to use ctest from the command line to run my tests with memcheck and pass in arguments for the memcheck command.
I can run ctest -R my_test to run my test, and I can even run ctest -R my_test -T memcheck to run it through memcheck.
But I can't seem to find a way to pass arguments to that memcheck command, like --leak-check=full or --suppressions=/path/to/file.
After reading ctest's documentation I've tried using the -D option with CTEST_MEMCHECK_COMMAND_OPTIONS and MEMCHECK_COMMAND_OPTIONS. I also tried setting these as environment variables. None of my attempts produced any different test command. It's always:
Memory check command: /path/to/valgrind "--log-file=/path/to/build/Testing/Temporary/MemoryChecker.7.log" "-q" "--tool=memcheck" "--leak-check=yes" "--show-reachable=yes" "--num-callers=50"
How can I control the memcheck command from the ctest command line?
TL;DR
ctest --overwrite MemoryCheckCommandOptions="--leak-check=full --error-exitcode=100" \
--overwrite MemoryCheckSuppressionFile=/path/to/valgrind.suppressions \
-T memcheck
Explanation
I finally found the right way to override such variables, but unfortunately it's not easy to understand this from the documentation.
So, to help the next poor soul that needs to deal with this, here is my understanding of the various ways to set options for memcheck.
In a CTestConfig.cmake in you top-level source dir, or in a CMakeLists.txt (before calling include(CTest)), you can set MEMORYCHECK_COMMAND_OPTIONS or MEMORYCHECK_SUPPRESSIONS_FILE.
When you include(CTest), CMake will generate a DartConfiguration.tcl in your build directory and setting the aforementioned variables will populate MemoryCheckCommandOptions and MemoryCheckSuppressionFile respectively in this file.
This is the file that ctest parses in your build directory to populate its internal variables for running the memcheck step.
So, if you'd like to set you project's options for memcheck during cmake configuration, this is the way to got.
If instead you'd like to modify these options after you already have a properly configured build directory, you can:
Modify the DartConfiguration.tcl directly, but note that this will be overwritten if cmake runs again, since this file is regenerated each time cmake runs.
Use the ctest --overwrite command-line option to set these memcheck options just for that run.
Notes
I've seen mentions online of a CMAKE_MEMORYCHECK_COMMAND_OPTIONS variable. I have no idea what this variable is and I don't think cmake is aware of it in any way.
Setting CTEST_MEMORYCHECK_COMMAND_OPTIONS (the variable that is actually documented in the cmake docs) in your CTestConfig.cmake or CMakeLists.txt has no effect. It seems this variable only works in "CTest Client Scripts", which I have never used.
Unfortunately, both MEMORYCHECK_COMMAND_OPTIONS and MEMORYCHECK_SUPPRESSIONS_FILE aren't documented explicitly in cmake, only indirectly, in ctest documentation and the Testing With CTest tutorial.
When ctest is run in the build, it parses the file to populate its internal variables:
https://cmake.org/cmake/help/latest/manual/ctest.1.html#dashboard-client-via-ctest-command-line
It's not clear to me how this interacts with
I need to run a distributed test with some of the command line parameter and also I need to pass My server IP with -Djava.rmi.server.hostname=IP, since I am running it from the command line I need nee to give as
jmeter -n -t C:\\Jmxfile.jmx -r Gsomeproperty=value in command line.
I am confused of passing even the command line parameter and also hostname? can somebody help me in sending both at a time.
Check the documentation:
Java system properties and JMeter properties can be overridden directly on the command line (instead of modifying jmeter.properties). To do so, use the following options:
-D[prop_name]=[value]
defines a java system property value.
-J[prop_name]=[value]
defines a local JMeter property.
-G[prop_name]=[value]
defines a JMeter property to be sent to all remote servers.
-G[propertyfile]
defines a file containing JMeter properties to be sent to all remote servers.
So, you can send both at a time through the command line.
I have created a toolchain, which downloads the code from the bitbucket repository and builds the docker image in IBM Cloud.
After the code builds the image, the build stage fails while building the artifactory.
Error:
Preparing the build artifacts...
Customer script does not exist for the job, exitting
I have specified the Build archive directory as the folder name. Do I need to write any scripts for archiving?
That particular error occurs when one of our checks -- the existence of /home/pipeline/$TASK_ID/_customer_script.sh -- fails.
Archiving happens automatically but that file needs to be present as we use it as part of the traceability around how the artifact was created. Is it possible that file is getting removed? (Also will look into removing or making the check non-fatal however that will take time)
This issue appears to be caused by setting a working directory for the job. _customer_script.sh gets dropped into the working directory, but the script Simon is referring to (/opt/IBM/pipeline/bin/ids-buildables-notify.sh) only checks the top-level directory the code input is at (/home/pipeline/$TASK_ID/).
Three options to fix this, assuming you're doing a container registry job:
Run cp _customer_script.sh /home/pipeline/$TASK_ID in your script. The ids-buildables-notify.sh script does some grepping for your bx cr build call, so make sure that's still in there.
touch /home/pipeline/$TASK_ID/_customer_script.sh and export PIPELINE_IMAGE_URL=<your image url>. If PIPELINE_IMAGE_URL is set, the notify script doesn't bother with being clever, which I prefer.
Don't change the working directory.
A script which works for me:
#!/bin/bash
echo -e "Build environment variables:"
echo "REGISTRY_URL=${REGISTRY_URL}"
echo "REGISTRY_NAMESPACE=${REGISTRY_NAMESPACE}"
echo "IMAGE_NAME=${IMAGE_NAME}"
echo "BUILD_NUMBER=${BUILD_NUMBER}"
echo -e "Building container image"
set -x
export PIPELINE_IMAGE_URL=$REGISTRY_URL/$REGISTRY_NAMESPACE/$IMAGE_NAME:$BUILD_NUMBER
bx cr build -t $PIPELINE_IMAGE_URL .
set +x
touch /home/pipeline/$TASK_ID/_customer_script.sh