I have a script and I can run it using execute shell and run as even parametrized by giving argument1 and argument 2 if I disable my warning message.My warning message do you want run yes/no but how we can give yes or no once we start the parametrized build. If I say yes it should continue if I say no it should stop.Any idea would be appreciated.
Thanks
Pravin
If your script is interactive, it will not work, since Hudson requires non-interactive scripts - otherwise it will just hang (there is no terminal).
What you can do is, instead of asking whether to continue, make it dependent on a variable, let's say CHOICE, so
...
if [[ "$CHOICE" == "yes" ]]
then
#do some work here
else
echo "Script ended."
fi
and put CHOICE as a choice-style parameter in Hudson. The next time you start the build, it will ask you "yes" or "no". You can also pick a default for automated builds.
It might be better to use some of the Hudson variables to indicate you are in a Hudson build (HUDSON_JOB_ID?) etc. This can be used to change the behavior of the build. I see the problem in having an interactive script for building. A build script must be running without interactions with the user.
Related
Can someone explain how being a "googler" or not affects how an open source package builds or not?
When attempting to build v8 the build docs state
"If you are a non-googler you need to set DEPOT_TOOLS_WIN_TOOLCHAIN=0"
When I set DEPOT_TOOLS_WIN_TOOLCHAIN to 0 as a "non googler" the build cuts short.
When I set DEPOT_TOOLS_WIN_TOOLCHAIN to 1 as a "googler" the build doesn't cut short but errors out later on in a way that points to requiring a specific hash value on the build system.
When inquiring about the error on the googlegroup v8-users an employee of google stated:
"It wouldn't enter this code if the environment variable I mentioned
was set correctly. If you do enter this code it's not set. And it is
expected to fail"
Which means the build is expected to fail for "non googlers".
He goes on to say that the build platform I'm on is not supported (non googler, no hash value...) yet that "it should compile at least".
?
Can someone explain how "it should compile at least" ?
If you are a "non googler" do you use another build script and build tools ? Possibly get the source otherwise and use different parameters ? Do you even attempt to build the package at all (in the sense that "non googlers" are not meant to build the package)?
If anyone has some experience here it would be helpful as it would save a lot of time and trouble for people trying to build packages with
set DEPOT_TOOLS_WIN_TOOLCHAIN=0 if you are not a googler
Thank you.
You should certainly be able to build V8. You do not need access to any special infrastructure or tooling. There are many V8 committers that are not Google employees.
That particular environment variable DEPOT_TOOLS_WIN_TOOLCHAIN is different for Google employees because of licensing reasons (distributing Microsoft toolchain via depot_tools), but you can build V8 with and without that variable.
I would like to force my cmake based configuration to fail ( and possibly print a message ) if:
there are unused variables ( which are likely to be a typo in most cases )
there are unused modules ( same thing as before or useless stuff )
a particular if is not being evaluated to TRUE
I find that the fact that cmake is macro based solution makes it hard to spot errors on big projects, so if someone has some some hints on that. Basically cmake doesn't alert you because anything could be a custom variable and not necessarily a typo or a mistake.
Let's address your points out-of-order.
a particular if is not being evaluated to TRUE
The way to achieve this is a FATAL_ERROR message:
if(SOME_CONDITION)
message(FATAL_ERROR "You did something wrong!")
endif()
there are unused variables
This is more difficult. There are the --warn-unused-vars and --warn-uninitialized command line options, but this has to be given by the user when running CMake. It is not possible to enforce this behavior from within a CMake script.
Also, there is no way to turn these warnings into fatal errors: CMake will still try to produce a valid Makefile (and may succeed in doing so). The only viable solution here seems to be developer discipline: Whenever a developer makes changes to the build environment, they should be aware of this compile options and check their code accordingly. Just as you would do with your other source code.
If you have trouble enforcing this, try to provide a shell-script as a wrapper that already sets all of the desired command line options. While not perfect, this will at least remove the obstruction of having to look up that damn parameter in the manual for your developers.
there are unused modules
This is not possible, but I also don't see a big problem here. Worst thing that can happen is that pulling in the module adds some noise to the cached variables, but none of that would have any influence on the final generated build files.
CMake modules should always be kept small enough so that pulling them in should have no noticeable impact on the runtime of your CMake configure run.
Hudson-CI shows a build as broken despite if the build was successful and only the unit tests are failing.
Could I configure it to show the red circle only on really broken builds, and show another color (let's say yellow) when the build is successful and only other condition is broken?
Hudson will report the build as failing if the exit/error code on the last step is non-zero. Our testing tool (NUnit) returns a zero only if all the tests passed, and I suspect your tests are doing similar.
To get round this, configure Hudson to have two build steps per job. The first step builds the code. If this step fails, the build fails and appears as a RED circle.
The second step runs the tests - but is set to always return a zero exit code. e.g. I have a Execute Windows batch command step with the following command:
NUnit-console.exe /options as required...
exit 0
The exit 0 forces Hudson to think that the tests have run OK. Thus if both steps are run, the job will be labelled as sucessful.
Finally, if you use the "Publish NUnit test result report" option, Hudson can inspect the test results and make the build either unstable (YELLOW) if some tests failed or successful (GREEN) if all passed.
(There are other options for JUNit, MSTest etc. but I've only got experience with NUnit and Hudson)
failonerrors="on" on task tag. Isn't it you're looking for ? Apache Ant - task
I'm working on a Mercurial GUI client that interacts with hg.exe through the command line (the preferred high-level API, as I understand it).
However, I am having trouble determining the possible outputs of each command. I can see several outputs by simulating situations, but I was wondering if there is a complete reference of the possible outputs for each command.
For instance, for the command hg fetch, some possible outputs are:
pulling from https://User#server.com/Repo
searching for changes
no changes found
if there are no changes, or:
abort: outstanding uncommitted changes
or one of several other messages, depending on the situation.
I would like to structure my program to handle as many of these cases as possible, but it's hard for me to know in advance what they all are.
Is there a documented reference for the command-line? I have not been able to find one with The Google.
Look through the translation strings file. Then you'll know you have every message handled and be able to see what parts of it vary.
Also, fetch is just a convenience wrapper around pull/update/merge. If you're invoking mercurial programmatically you probably want to keep those three very different concepts separate in your running it so you know which part failed. In your example above it's the 'update' failing, so the 'pull' would have succeeded and the 'update's failing would allow you to provide the user with a better message.
(fetch is an abomination, which is part of why it's disabled by default)
Is this what you were looking for: https://www.mercurial-scm.org/wiki/MercurialBook ?
Mercurial 1.9 brings a command server, a stable (in a sense that API doesn't change that much) and low overhead (there is no need to run hg process for every command). The communication is done via a pipe.
I am new at this and I was wondering how I can setup that I save the artifacts, only if less than 90% of the tests have passed.
Any idea how I can do this?
thanks
This is not currently possible with Hudson. What is the motivation to avoid archiving artifacts on every build?
How about a rather simple workaround. You create a post build step (or additional build step) that calls your tests from the command line. Be sure to capture all errors so Hudson don't count it as a failure. Than you evaluate your condition and set the error level accordingly. In addition you need to save reports (probably outside hudson) before you set the error level, so they are available even or only when the build fails.
My assumption here is, that it is OK, not to run the tests when building the app fails. However, you can separate the building and testing in two jobs. See here.