I am working on a testing automation project and I am able to automate end to end test cases but in my scope I have to enable functionality to run test-case when a workflow is checked-in to repository. For this I need a trigger with information like what workflow and in which folder is checked it's checked in. Unfortunately I am unable to get anything till now and my admins are also not sure if this can be achieved. Any lead will be a great help.
Even if I can get the logs of workflow check-in, I can process them in real-time to get this information.
Related
I've not been able to find any way in Concourse to show a 'build summary page' as you get in Jenkins/TFS etc. In those tools you can see build history (OK/failures), build durations, unit test results, code coverage, various graphs etc - but Concourse just has build history which is simple log files.
There doesn't seem to be any extensions system or other way to achieve this.
I'd prefer to use Concourse for the pipelines and build-in-containers approach, but it's a hard sell to developers who see it as a step backwards.
Thanks
Paul
The containers/workers of your plan/build are spinned up and spinned down. Everything you want to keep you need to PUT to a resource. In the concourse ecosystem there are many resources created.
The results and output logs of your builds/jobs are by default available in concourse UI (ok/not-ok, time). See for example: https://ci.concourse-ci.org/teams/main/pipelines/main/jobs/build-fly/builds/1273 In the job itself you can expand and see the logs, so output log of your unit tests for example.
If you want to keep the sonar report you just install a resource like https://github.com/cathive/concourse-sonarqube-resource and you can simply run this after your unit test by using the PUT (and store it on your Sonar server). So indeed you have no html report you can keep on that specific build, but you can put it everywhere you need it to be by using/creating a plugin. Very simple and nicer because the whole Sonar overview of your project is where it belongs :)
let me begin by saying I 'm a coldfusion newbie.
I 'm trying to research if its possible to do the following and what would be the best approach to achieve it.
Whenever a developer checks in code into SVN, I would like to do a get all the new changes/files and do an auto build to check if the code can be deployed successfully to production server. I guess there are two parts to it, one syntax checking and second integration test(if functionality is working as expected). For the later part some unit test tools would have to be used.
Can someone comment on their experience doing something similar for coldfusion.
Sorry for being a bit vague...I know its a very open-ended question but any feedback would be appreciated.
Thanks
There's a project called "Cloudy With A Chance of Tests" that purports to do what you require. In particular it brings together a number of other CFML code analysis projects (VarScope & QueryParam) to check code, as well as unit testing. I am not currently using it myself but did have a look at it some time ago (more than 12 months) and it appeared to be quite good.
https://github.com/mhenke/Cloudy-With-A-Chance-Of-Tests
Personally I run MXUnit tests in Jenkins using the instructions from the MXUnit site - available here:
http://wiki.mxunit.org/display/default/Continuous+Integration+--+Running+tests+with+Jenkins
Essentially this is set up as an ant task in Jenkins, which executes the MXUnit tests and reports back the results.
We're not doing fully continuos integration, but we have a process which automates some of the drudgery of our builds:
replace the site's application.cf(m|c) with one that tells users that the app is being deployed (we had QA staff raising defects that were due to re-deployments)
read a database manifest XML which lists all SQL scripts which make up the current release. We concatenate the scripts into a single upgrade script, suitable for shipping
execute the SQL script against the server's DB, noting any errors. The concatenation process also adds a line of SQL after each imported script that white to a runlog table, so we can see what ran, how long it took and which build it was associated with. If you're looking to replicate this step, take a look at Liquibase
deploy the latest code
make an http call to a ?reset=true type URL to tell the app to re-initialize
execute any tests
The build is requested manually through the build servers we have, but you click a button, make tea and it's done.
We've just extended the above to cope with multiple servers in a cluster and it ticks along nicely. I think the above suggestion of using the Jenkins SVN plugin to automate the process sounds like the way to go.
Is it possible to use the CruiseControl tool with a C++ (Mingw) project on Windows? I need to be able to download the latest sources from XVN, build them, send reports by mail. The application is using http server (lightpd) for work.
So main question is have to use it for email notifications?
Problem is I dont see any destination field in email tag.
I am interested in sending email notifications after build which executes in batch file.
E. g. in my config file I call batch file which executes build, after that I need to send email notification, how can I do it ?
Of course it is possible. There is a Java for Windows, a command line SVN clients, you can invoke gmake or any other build system you are using along with Cygwin, there is even a support for a Visual Studio projects if you need it. There are a lot of people using Cruise Control for C++ projects, thus a lot of documentation, tutorials and examples available online.
Perhaps not exactly what you're asking for, but is there anything preventing you from using Jenkins? People I've talked to that maintains the continuous integration for a living that have used both Jenkins as well as cruise control prefers Jenkins. Of course the bonus with Jenkins is that it's free.
If you can create a script that checks out and builds your project from the command line (in Cygwin's bash, for example), then you can certainly integrate the build into cruise control or Jenkins.
I don't know much about cruise control, but we use Jenkins a lot, and even though it has bugs that need to be worked around overall we find it extremely useful for CI and nightly build jobs.
Regarding the email aspect, Jenkins can be configured to watch the SVN log and when a build fails it can send an email to the people that committed changes since the last successful build. This functionality can be enabled with minimal configuration. There are add-ons that allow you to configure the content of the emails as well.
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 am trying to work out a good way to run a staging server and a production server for hosting multiple Coldfusion sites. Each site is essentially a fork of a repo, with site specific changes made to each. I am looking for a good way to have this staging server move code (upon QA approval) to the production server.
One fanciful idea involved compiling the sites each into EAR files to be run on the production server, but I cannot seem to wrap my head around Coldfusion archives, plus I cannot see any good way of automating this, especially the deployment part.
What I have done successfully before is use subversion as a go between for a site, where once a site is QA'd the code is committed and then the production server's working directory would have an SVN update run, which would then trigger a code copy from the working directory to the actual live code. This worked fine, but has many moving parts, and still required some form of server access to each server to run the commits and updates. Plus this worked for an individual site, I think it may be a nightmare to setup and maintain this architecture for multiple sites.
Ideally I would want a group of developers to have FTP access with the ability to log into some control panel to mark a site for QA, and then have a QA person check the site and mark it as stable/production worthy, and then have someone see that a site is pending and click a button to deploy the updated site. (Any of those roles could be filled by the same person mind you)
Sorry if that last part wasn't so much the question, just a framework to understand my current thought process.
Agree with #Nathan Strutz that Ant is a good tool for this purpose. Some more thoughts.
You want a repeatable build process that minimizes opportunities for deltas. With that in mind:
SVN export a build.
Tag the build in SVN.
Turn that export into a .zip, something with an installer, etc... idea being one unit to validate with a set of repeatable deployment steps.
Send the build to QA.
If QA approves deploy that build into production
Move whole code bases over as a build, rather than just changed files. This way you know what's put into place in production is the same thing that was validated. Refactor code so that configuration data is not overwritten by a new build.
As for actual production deployment, I have not come across a tool to solve the multiple servers, different code bases challenge. So I think you're best served rolling your own.
As an aside, in your situation I would think through an approach that allows for a standardized codebase, with a mechanism (i.e. an API) that allows for the customization you're describing. Otherwise managing each site as a "custom" project is very painful.
Update
Learning Ant: Ant in Action [book].
On Source Control: for the situation you describe, I would maintain a core code base and overlays per site. Export core, then site specific over it. This ensures any core updates that site specific changes don't override make it in.
Call this combination a "build". Do builds with Ant. Maintain an Ant script - or perhaps more flexibly an ant configuration file - per core & site combination. Track version number of core and site as part of a given build.
If your software is stuffed inside an installer (Nullsoft Install Shield for instance) that should be part of the build. Otherwise you should generate a .zip file (.ear is a possibility as well, but haven't seen anyone actually do this with CF). Point being one file that encompasses the whole build.
This build file is what QA should validate. So validation includes deployment, configuration and functionality testing. See my answer for deployment on how this can flow.
Deployment:
If you want to automate deployment QA should be involved as well to validate it. Meaning QA would deploy / install builds using the same process on their servers before doing a staing to production deployment.
To do this I would create something that tracks what server receives what build file and whatever credentials and connection information is necessary to make that happen. Most likely via FTP. Once transferred, the tool would then extract the build file / run the installer. This last piece is an area I would have to research as to how it's possible to let one server run commands such as extraction or installation remotely.
You should look into Ant as a migration tool. It allows you to package your build process with a simple XML file that you can run from the command line or from within Eclipse. Creating an automated build process is great because it documents the process as well as executes it the same way, every time.
Ant can handle zipping and unzipping, copying around, making backups if needed, working with your subversion repository, transferring via FTP, compressing javascript and even calling a web address if you need to do something like flush the application memory or server cache once it's installed. You may be surprised with the things you can do with Ant.
To get started, I would recommend the Ant manual as your main resource, but look into existing Ant builds as a good starting point to get you going. I have one on RIAForge for example that does some interesting stuff and calls a groovy script to do some more processing on my files during the build. If you search riaforge for build.xml files, you will come up with a great variety of them, many of which are directly for ColdFusion projects.