Once I commit the change in git, build is not starting automatically in Team city. I have enabled per-checkin triggering(both the check boxes), even after the bbuild is not started automatically(currently im running manually). Can anyone suggest the possible solution. Thanks in advance.
Related
In TDS Classic, is there a way to vary the "Item Deployment" property of an item by build? The use case is: I have test content that should be "Always Update" for Dev but it should be "Deploy Once" on QA
Is this possible? If not, whats the best practice around these scenarios?
Thanks
One simple way to handle this is to create a separate TDS project dedicated to DEV related content that's set to Always Update.
In your build configuration you can allow for the generation of multiple update packages. The last step is ensuring that the DEV update package is never installed beyond DEV. How you handle that will depend on how you're installing the update packages upstream. If it's a manual installation, then there's no problem. If it's an automatic installation, you'll need to exclude the DEV update package.
The approach above has the added benefit of being able to easily sync in your local environment very quickly and stay in sync with other developers who will also keep that developer TDS project up to date..
I am working on setting up a new build server using Team City 2017.2.
Our source control (TFS 2015) is structured like this:
Trunk
Branches
Branch1
DEV
UAT
Branch2
DEV
UAT
etc...
I have setup a build that is working using a vs root pointed at a specific DEV branch and Trunk.
Each new project gets its own branch that I create in TFS at the project's start. Coding takes place DEV. We want to setup the Team City build so that it automatically will build the branch that has a check in. A build.proj file is what controls what code the build server builds in the branch.
We are trying to avoid having to manually maintain a seprate VSC roots and builds for each branch as branches are created and merged to trunk/deleted as projects are completed.
I am having trouble figuring out if this is possible and if so how to do it. Can someone point me in the right direction on this?
Thanks in advance,
-Wayne
I am working on a Continuous Integration project where I need to install update packages in Sitecore instances and roll back the update package if something goes wrong. I am creating the update and rollback update package using Sitecore Courier. I just want to know if there is any mechanism to confirm that my rollback worked correctly i.e. the Sitecore instance has been restored to its previous state.
I don't think you have something out of the box to check if something goes wrong.
I suggest you to create few unit tests using Sitecore FakeDb and check if old
templates still exist, if content is the same,etc
Informations about FakeDb you can find at: https://github.com/sergeyshushlyapin/Sitecore.FakeDb/wiki
Is it possible to trigger a Hudson/Jenkins build only when a certain string appears in a commit-message?
For instance, I want to trigger a build that rolls out my application to the dev environment by writing a commit message like:
MYPROJECT-123 Fixed NPE in MyClass.java #deploy:DEV
The general idea is described in this great talk on Continuos Deployment but I couldn't find any information on how to do this in Hudson.
I would prefer to have this behavior in Hudson itself and not in an external system like commit-hooks or web-hooks.
I don't know of an out of the box way you can parse the SCM message as part of the trigger. You have a couple of options that might achieve what you want though
Write your own Hudson SCM plugin
Chain your jobs together into a build pipeline. The first job could simply look for that message in the changelog.xml to determine if the next build is triggered or not.
If you are looking at building a pipeline of build jobs, check out the build-pipeline-plugin. http://www.centrumsystems.com.au/blog/?p=121
Anyone got a more elegant solution??
Cheers,
Geoff
There is a plugin called Commit Message Trigger Plugin, but it had just a 0.1 release.
Maybe the easiest way is to use a version control post commit (or push) trigger to start a Hudson Job. You'd one anyway to automatically start your build.
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)