I was trying to find out who triggered the failing Hudson build. But i found Started by an SCM change instead of Started by 'UserId'. Now, what does that mean?
It means that someone checked in code changes to your version control system / software configuration management (CVS, SVN, Git, etc), and Hudson started a built based on that change.
You should be able to see who it was by clicking the "Changes" link on the left menu.
"SCM" is "software configuration management", i.e. your version control system. Hudson can be configured to poll CVS, SVN etc for changes to your source code, and trigger a build based on that change.
I was working on a script to fire off an email with a list of changeset to a developer who started the build. After spending a couple hours on the web trying to search for a solution, I found a workaround digging through hudson log files. Probably not the cleanest way of doing it, but it works. Every time when hudson fire off a build, it records the build status to a log file. The log looks something like this..
Started by user <****>
Building remotely on Slave1
$ hg clone -r test_clone https://mercuial.com/build /some/workspace/test_clone
adding changesets
adding manifests
adding file changes
added 355 changesets with 298 changes to 43 files
updating to branch default
41 files updated, 0 files merged, 0 files removed, 0 files unresolved
...
...
The log file is in ~workspace/jobs/${RELEASE}/builds/${BUILD_NUMBER}/log. You can then parse the log file for the UserId. Something like this should work.
UserID=head -1 ~workspace/jobs/${RELEASE}/builds/${BUILD_NUMBER}/log|cut -d" " -f4
Had the same problem in jenkins when checkout branch name and specified branch name where same. Any change triggered hudson to automatically create a build to catch-up.
solved by: change local branch name to something else (or don't use it, maybe)
Related
We are using Build Pipeline in Azure DevOps to create a Deployment Artifact. Typical steps in such pipeline are:
Build Solution / Project
Copy dlls output into $Build.ArtifactStagingDirectory
Publish Artifact from $Build.ArtifactStagingDirectory
I just wonder if I can rely on the fact, that on start of each Build the Build.ArtifactStagingDirectory is empty. Or should I clean the folder as first step to be sure?
From my experience the folder was always empty, but I am not sure if I can rely on that. Is that something specific to Azure hosted Agent and maybe by using custom Build agents I have to do manual clean-ups of this folder? Maybe some old files from last build could remain there? I did not found this info in documentation.
Thanks.
I think that the main idea of this variable $Build.ArtifactStagingDirectory is to be a clean area so you can manage the code you're pushing from your repo. As far as I know, there is no explicit information on documentation talking that this folder is empty at every new build, but there are a few "clues":
You can see at the Microsoft's Build Variables documentation that Build.StagingDirectory is always purged before each new build, so you have a fresh start every build.
In the documentation above you have a few cases where it explicitly cites that some folders or files are not cleaned on a new build, like the Build.BinariesDirectory variable.
I've run a few build and realeases pointing to my Web App on Azure, and I never saw an unwanted file or folder that was not related to my build pipeline.
I hope that helps.
I have done a number of changes to a build configuration in TeamCity 8. I know I can see an audit trail of the changes that I have done to the build configuration and I can check the details of each individual change, but I wonder if I can select one of those previous versions of the build configuration and restore it; there doesn't seem to be any obvious option in TeamCity for this.
For the avoidance of doubt, I'm not after reverting changes in the source code, but in the build configuration of TeamCity. I changed a few parameters, build steps, triggers, etc., and I want to revert those changes.
You are right ,there is no obvious option in Teamcity to rollback to a previous version.
However, all teamcity build configurations are maintained in a xml file on the local disk drive in the Local Build Server. The files are created in a rolling format (the latest config is called config.xml, the one previous to it is config-1..xml). If you can figure out from the audit page on which exact xml you want to rollback to, you can copy the backed up config.xml to the recent one, or you can make the changes manually.
I would recommend playing with this on a test target first and then doing it on the original target.
As of TeamCity 2017, there is a link to a page with recent changes to a configuration:
Press 'view history' and you will end up on a page where there's a list of changes.
Press 'view change':
There you will see a "diff" comparison, identical to the one you have in git:
Sometimes it's hard to navigate, but you can surely see what was changed. This is especially useful for accidents when you deleted a piece of script, and saved the configuration. This can get your script back.
Hope it helps you after you after 8 years and 4 months!
Hopefully I find here someone who has experience with Hudson and its functions.
Now . I have Hudson installed this did not reveal any problems. But now I want to create a new job and that I'm developing in C / C + +.
In addition, I am working on Subversion svn where I run on the first error. Hudson did not find my svn . He says that I need an authentication . As I learned I can at Hudson authenticate but that does not work .
Maybe one of you knows how to create a project.
The things should be done in the job of Hudson.
Hudson is on my computer (local ) delete my project.
Then Hudson to access my SVN and check out the project from there.
The whole is now compiling Hudson . ( The best would be a compiler for C / C + + for Visual Studio 2008 compiler ) . The compiler then creates a * . Exe file.
Now Hudson to start the project on the basis of the *. Exe file and run the program .
Last but not least is to Hudson case of an error or if it was all right, inform the persons working on the project via email.
So that would be it what I 've hoped of Hudson. Otherwise, I take the whole not much. I know that I can do all this via a batch file . But that's not my goal. I want Hudson to automate so that I can start at midnight my builds / tests daily.
Do you think that at Hudson are my requirement too high?
For your help I would be very grateful , as I am stuck for days.
Here is a "basic" Hudson job
Create a new free-style software project job.
Configure that job.
(Optional) Configure triggers, such as "timer", "SCM polling", or others.
(Optional) Under Source Code Management section, select your SCM source and configure your repositories and local workspace
Under Build section, select Add build step and select:
Execute Shell if on *nix
OR
Execute Windows Batch Command if on Windows
OR
Pick whatever build-step plugin you are using.
(If using either of the "execute" build steps) Write your build/make/compile command as you would from command line.
(If using another plugin build step) Configure the plugin options according to your requirements.
(Optional) Archive the artifacts of the build with Archive the artifacts under Post-build Actions
(Optional) Execute other post-build actions
(Optional) Send out an email
Now to address your specific scenario. First things first, your question is too broad, and may get locked. Don't get discouraged if that happens, create separate question for each item individually. I cannot cover in details all these items, but I will give you an overview.
The SCM part
Based on your previous question, No Credentials to try in Hudson, I am now guessing that you are not providing Hudson with an HTTP URL to your SVN server, but trying to give it your local workspace location... Please do the command line check that I asked in that question.
You need to provide it with a proper HTTP server URL. Hudson will check out the project from the SVN URL you provided, under what is called a Workspace. The location of workspace can differ, based on your Hudson configuration, but it is a folder inside Hudson installation that is dedicated to the job. It can be referenced from within the job through %WORKSPACE% environment variable.
There are ways to use a different workspace location, but that is outside the scope of this overview. The whole SCM part is also optional, you can rely on existing file system, but this is not a good approach, and again, out of scope of this overview.
The Build step
After Hudson checked-out/updated the Workspace with your SVN, comes the building step. Hudson can do Execute Windows Batch Command by default. It can also Invoke Ant by default. (It can also do Maven, but that is not applicable to your situation)
To do other types of builds, you need a Build Wrapper plugin. In your particular case, the MSBuild plugin is probably what you want. I've never used MSBuild, so cannot give you details. Again, if you have a specific question on how to use MSBuild plugin, you should probably make a separate question with specific issues.
So, using either Execute Windows Batch Command or MSBuild plugin, configure your building step.
Running the exe???
This is very vague. You want to start the .exe and then what? Will it quit and you need an exit code? Do you want to see it on the screen? Again, this is very broad, and deserves a separate question (or read existing questions). If you just want to make a call to the .exe, you can configure a second Execute Windows Batch Command step, type there call path\to\yourfile.exe. But most likely you will not see that on screen. Read my answer here, Open Excel on Jenkins CI, on details of launching an .exe from Hudson/Jenkins that would be visible on screen.
Email
If you want a simple email, Hudson Post-Build actions has a way to send an email. For better customization options, you would want Email-Ext plugin. Once again, if you need details on how to use the email-ext plugin, create a new question (after searching existing questions first), as this is too much to cover in one question.
Conclusion
Your requirements are not too high, but Hudson is not a magic tool that will do the work for you. You still need to configure every step of it. And unless you have a Maven based project (which integrate very well with Hudson), a lot of actions will need to be done through the Execute Windows Batch Command and scripting of your own.
I am starting to prepare a roadmap for our release process. We are at present using tortoise svn and ant for building source. I am considering implementing continuous integration and would like to know right direction for the choices below:
Firstly, the present process is such that a developer would work on a file, commits that file directly to repo. Others would run the tortoise update command to pull in the required changes. The same process is followed on the build server where in would update the source code, build and then deploy to qa and production servers. However, this process lacks control of repo since during an update, unwanted code is also pulled in case two developers worked on the same file fixing two different issues. One approved by qa and other rejected. How can i overcome this scenario.
Secondly, apart from source we have a bunch of other files such as xml files, css,js etc . How do i automate deployment of these files? I have configured cruisecontrol on my local machine and it works fine when it comes to executing a build but now sure how to handle other files since updating those files in production seems risky and error prone. Any suggestion in this would be really helpful.
You could try integrating PowerShell with CruiseControl, our team has CC fire off the build process and then PowerShell to copy the resulting project files (code and others) to production or a test site or wherever.
I'd suggest to deal with the lack of repository control that you create a candidate Branch off your Trunk and designate that as your Integration code. Once it's settled and necessary changes have been committed or pulled, promote it to Regression for further testing. Then once that testing is successful, promote it to Production.
In this process your developers wouldn't be committing to Production directly, but instead through an iterative process a new production repository will result, whose changes can then be reintegrated into Trunk so the process can start anew for the next release.
I have configured Jenkins and created a job to checkout, build and run a simple project from SVN. I could configure this job to run periodically, like once every five minutes. But I'd like it to build the project only when something has changed on the SVN repository. I read the "Builds by source changes" section of this document, but could not figure out what exactly I am meant to do! Any help would be appreciated!
When you configure your job you have to do this:
In the Source Code Management specify the source management system you use (for instance SVN) and fill all required fields (url, authentication, ...) (probably already done since you are able to do a checkout)
in the Build Triggers section : choose Poll SCM with a schedule */10 * * * * for checking the repository every 10 minutes.
Go to the configuration of your project and scroll down to the Build Triggers directly under the Source Code Management section. Here you've to configure it this way:
The syntax to schedule the job is in the crontab format take a look here.
what you are looking for is Subversion post commit hook that will execute what ever you script in your hook script. Take a look at the following example by Mike West:
Mike West - Subversion Post-commit-hook
good luck!