I was wondering if it is possible if I could include a Fix List with my deployment build email notification,what I was expecting is I would add the latest changes to a text file stored in a directory and CruiseControl.NET would pick it from there and send along with the email.Anybody has any similar solutions, or how did you do it? Any samples or links?
Thanks in advance.
The first question is whether you do continuous integration (CI) builds or just periodical builds? In case it is CI, have you tried writing this fix list into the check-in comment of your version control system? CCNet shows this comment as part of the build report (and email notification).
UPDATE: the other option I see is to write your own CCNet plugin for this. It shouldn't be too hard. As a reference on writing CCNet plugins you can use my own BrekiLabeller plugin.
Related
I understand that gitlab has support to Jenkins CI, but what I need is a lot less than that.
I have a Rails application and get the coverage from the tests using simplecov. It generates HTML output in a directory by running a rake task. I would like to see the current coverage through gitlab. Is there a simple way to integrate this report with gitlab?
I fear there is still no easy way to integrate code coverage reports but Gitlab now supports (since Version 8.0 integrated) build jobs for your code. Unfortunately you have to implement your solution by writing a custom .gitlab-ci.yml to run your coverage tests. For viewing the reports, you can specify the generated "artifacts" or publish them on gitlab pages.
For more information, see here: https://about.gitlab.com/gitlab-ci/
Additionally you can parse a text output to display a short code coverage report:
(Enable builds and output test coverage)
Go to "Project Settings" -> Builds
Add to "Test coverage parsing" a regular expression (examples below, simplecov included)
See Publish Code Coverage Report with GitLab Pages
The short answer: Unfortunately there is no easy way to do this.
The longer answer:
GitLab not yet has a Jenkins support.
What you basically need is a service like GitLab CI or Jenkins CI, which starts simplecov and posts the output back to GitLab. Unfortunately GitLab does not offer such a functionality yet.
But I know other organizations which do have a Jenkins service for GitLab which automatically comment git pushes with the Jenkins result.
You now (June 2020, GitLab 13.1) have code coverage history, in addition of Test coverage parsing.
Graph code coverage changes over time for a project
All too often, a project has a code coverage target but development teams might not have much visibility into which direction that target value is trending over time.
There needs to be an easier way to track changes in code coverage over time without that extra hassle.
The Code Coverage graph now provides better visibility into how code coverage is trending over time.
It displays a simple graph of the coverage value(s) calculated in pipelines.
See Documentation and Issue
With GitLab 13.6 (November 2020), you also have (not for free though)
Display code coverage data for selected projects
In 13.4, we released the first iteration of Code Coverage data for Groups that enables you to compare the coverage of multiple projects and download the data in a single file from a single screen. However, to analyze the data, you had to open the file to check it manually, and probably imported it into a spreadsheet for further analysis.
In GitLab 13.6, you can now select specific projects in a group to see their latest coverage values directly in GitLab itself without needing to download a file or waste development time accessing code coverage data. We welcome feedback on the functionality and possible iterations for this feature in our feedback issue.
See Documentation and Issue.
I Have managed to create a CI project that uses GIT as it's source control, and an MSBuild extension to label the assemblies based on the CCNet build label, and commit that changed label
I have other projects that are manually triggered to publish this version to particular sites etc.
I would like the project status in the dashboard to display the build label (eg 2.1.345.0) from the assembly, or from a built dll, so that we can easily see which revision was published at the last manual trigger.
There's plentyof info on updating assembly info for a build, but nothing on using a assemby ifnfo version for the displayed 'last build label'
Any Ideas anybody ? Do I need to create a task to manually update the state file ? that sounds a bit dodgy.
Thanks in advance
None of the built-in labellers does what you need, but you should probably be able to write your own custom labeller to that.
You can find two custom labellers with source code here and here to get you started.
I have a large web project and I would like to publish only the files that were modified by the last checkin. What would be the best way to do this?
I found an article that detailed the process using robocopy. I thought perhaps there was a task in ccnet that did this, but I couldn't find one.
http://msmvps.com/blogs/omar/archive/2008/10/06/asp-net-website-continuous-integration-deployment-using-cruisecontrol-net-subversion-msbuild-and-robocopy.aspx
It depends on what you are doing. Do you use a build script? Your best bet is to let your build script do your publishing, you will have much more control over it.
There is a Modification Writer Task that will create an XML file of the detected modifications in that build. You could then have your build script read that and publish just those files.
There is also a Modification Reader and the doc implies that you can use the read in modifications and publish based on that list:
The ModificationReaderTask can now easily read the modification
file(s) made by project one, into it's
own integration,
making it possible that these can be used by the existing
tasks/publishers of ccnet for project
2
However, it doesn't make it to obvious how you would do this. Perhaps the BuildPublisher will use the Modification Reader info. This might get you started.
Is there any way that NANT would do a force checkout from source control or force checkin even if there is newer version in source control?
I not an nant guy, but could you explain what is the purpose of it?
Forcing checkin automatically looks to me like a bad idea - if I modified file by mistake I don't want it to be automatically checking without my innervation.
If you were using a CruiseControl.NET source control block then you could specify cleanCopy="true" to delete the working copy before updating the source.
I assume you want to circumvent the normal CruiseControl.Net checkout mechanism? You will have to execute the source control command line yourself, or use something like NAntcontrib.
Please specify what source control engine are you using.
I've been doing some research into finally automating our Development builds and still have one nagging question that I'm hoping the StackOverflow community can solve for me.
My understanding is that an IntervalTrigger when setup properly will check VSS every X seconds for changes and if it finds a modified file, will run my tasks. One of my tasks would be to checkout the AssemblyInfo files and update the version numbers. After these files are updated they would be checked back into VSS.
Thinking about this solution it doesn't make much sense because in my mind, I'm forcing the check for changed files to true every time the trigger fires. Am I missing something here? Is there a way of doing this without triggering an automatic build on the AssemblyInfo check-in?
You can use a Filtered Source Control Block to exclude certain files from the trigger.
I just posted a bunch about my default build process here which may be of some interest to you: SVN Website Development and Deployment Solution
The way I usually configure my projects with CC.NET is to have two project blocks per solution. One configured as an interval trigger that does nothing more than get the latest from my repository, build the solution, and run unit tests. The other is a schedule trigger that does all the things the other one does, but actually publishes a build. This includes changing version numbers, publishing files, etc. This might work in your case, since the change in version would cause the interval project to trigger, but only once.
Checking the automatically generated AssemblyInfo into the version control system is a bad idea, don't do it. You'll get a lot of noise (50% of all commits!) in your history. Also, it does not give you any new information - you can always pull this from VCS. Have your build script autogenerate those files is a good practice, but don't push those changes back!