The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,839 other subscribers

Archive for the ‘Continuous Integration’ Category

« Previous Entries
Next Entries »

KirillOsenkov/MSBuildStructuredLog: A logger for MSBuild that records a structured representation of executed targets, tasks, property and item values

Posted by jpluimers on 2017/05/31

Cool: KirillOsenkov/MSBuildStructuredLog: A logger for MSBuild that records a structured representation of executed targets, tasks, property and item values

Basically it parses the XML output into something manageable.

Via Matthijs ter Woord.

–jeroen

Posted in .NET, Continuous Integration, Development, msbuild, Software Development | Leave a Comment »

Version 1.8.1 History – builds 121-185 – Continua CI

Posted by jpluimers on 2016/12/07

I’ve been very busy with broken hardware and operating systems lately so today was the first chance to post about recent Version 1.8.1 History of  Continua CI. During October and November the below builds got released.

For almost all of them, you will need to update your agents after installing the build.

v1.8.1.185, November 23rd, 2016

Changes

  • Update: Added preliminary support for Visual Studio 2017 RC to MSBuild, VSTest, MSTest and Visual Studio actions
  • Fix: Issue where ExecuteRepositoryServerSideScripts app setting was not being read preventing running of Git post commit scripts.

v1.8.1.178, November 22nd, 2016

Changes

  • Fix: “changeset.style” file was missing from installer causing error when getting new changesets for new Mercurial repositories.
  • Fix: Issue where Shared Resource Locks at the configuration level would be released before the end of the build, if Shared Resource Locks existed at the stage level and were released.
  • Fix: Build version is now truncated to fit into the maximum field length of 128 characters.
  • Update: Email publisher now supports wider range of secure sockets options. This also fixes an issue where you it would always try to use TLS if it was supported by the server.

v1.8.1.167, November 15th, 2016

Changes

  • Fix: Issue where enabling a configuration would cause all time triggers in other configurations to stop working.
  • Update: Any updates to loggers in the Continua CI Server service configuration file, such as enabling debug logging, are no longer reset when running the installer.

v1.8.1.165, November 14th, 2016

Changes

  • Fix: Repository error status was being reset to “Ready” status when getting new changesets.
  • Fix: Associated triggers are now updated to point to the new repository when repository edit requires it to be recreated.
  • Fix: Concurrency issue with build event handlers causing incorrect build data to be used.
  • Update: Bundled Mercurial used for repository cache has been upgraded to version 3.9.2
  • Update: Improvements to speed when exporting files from agent repository cache to agent workspace.
  • Update: Agent installer has been updated to allow it to be run silently and take additional command line parameters. The relevant parameters are:
    • /usage (optional) – shows usage information.
    • /silent (optional) – runs the setup in silent mode. Note that progress bars will still be displayed.
    • /verysilent (optional) – runs the setup in completely silent mode. No UI is displayed.
    • /log=”filename” (optional) – creates a log file with the specified filename.
    • /dir=”x:\dirname” (optional) – overrides the default installation directory name.
    • /serviceUser (required in silent modes) – the domain and user name of the service user e.g. domain\username.
    • /servicePassword (required in silent modes) – the password of the service user.
    • /serverHostName (optional) – the host name of the ContinuaCI service. Defaults to “localhost” if not provided.
    • /serverPort (optional) – the port of the ContinuaCI service. Defaults to 9000 if not provided.
    • /agentPort (optional) – a port for the agent being installed. Defaults to 9002 if not provided.
    • /workspacePath (optional) – the local path to the agent workspace folder. Defaults to “C:\CI_AWS” if not provided.
  • Update: Now showing the finished time for the last finished build rather than Never for the last queued/running build on List View dashboard.
  • Update: JUnit parser now includes test case times.
  • Update: Diagnostics report is now generated in the background to prevent timeouts.
  • Update: Further improvements to build queue performance.

v1.8.1.121, October 11th, 2016

Changes

  • Fix: Regression bug in v1.8.1.118 where Path Exists property collector plugin would always return false.

–jeroen

Posted in Continua CI, Continuous Integration, Development, Power User, Software Development | Leave a Comment »

Continua CI v1.8.1.118 released

Posted by jpluimers on 2016/10/11

Source: Version 1.8.1 History | Continua CI – v1.8.1.118

v1.8.1.118

October 10th, 2016

Changes

  • Update: Reduced CPU usage on server when using a large number of time triggers.
  • Update: Reduced wait time between time triggers running simultaneously.
  • Update: Reduced CPU usage and throughput of stage queue.
  • Update: The >> operator is now implemented in repository rules. This is used to clean the destination folder before copying files. It is useful when a stage can run on the same agent as a previous stage as the agent workspace is not automatically cleared between stages.
    Note: We have also changed the default workspace and repository rules so that the >> operator is used for any server to agent rules in new stages. This is to ensure that the workspace is always cleared and are no surprises dependent on the agent the stage runs on. This can be changed to a single > to use the previous behaviour.
  • Update: Environment variables now expanded in all path type property collectors. This will for example allow you to use %HOME% to define the path to check when using a Path Access PlugIn property collector.
  • Update: Added descriptions and help information to property collector dialog fields.
  • Update: Queued stages are now prevented from starting in the few seconds after an agent has gone offline.
  • Fix: Issue where changes to user group membership were not picked up for several minutes unless the service was restarted.
  • Fix: Triggers were not being monitored after a disabled configuration was re-enabled.
  • Fix: Issue where agents with unlimited concurrent stages would not be selected to run stage.

–jeroen

Posted in Continua CI, Continuous Integration, Development, Software Development | Leave a Comment »

Released: Continua CI v1.8.1.112

Posted by jpluimers on 2016/09/29

Version 1.8.1 History | Continua CI:

v1.8.1.112

September 29th, 2016

Changes

  • Fix: Regression bug: repository branch auto-mapping changes were missing a null check causing triggering builds to be stuck in initialising state.
  • Fix: Branch auto-mapping was not working with all scenarios.
  • Update: Property collector added for .Net Framework 4.6.2.

Posted in Continua CI, Continuous Integration, Development, Software Development | Leave a Comment »

TODO: Check if Continua CI parsesl DUnit XML FinalBuilder emitted XML when using pure DUnit tests and TRepeatedTest ones

Posted by jpluimers on 2016/09/29

On my TODO list.

References:

This in order to get rid of MSXML dependencies in cross platform Delphi development.

–jeroen

Posted in Continua CI, Continuous Integration, Delphi, Development, DUnit, Software Development | 2 Comments »

New Continua CI version v1.8.1.108

Posted by jpluimers on 2016/09/29

via Version 1.8.1 History | Continua CI [WayBack]: new version v1.8.1.108

September 28th, 2016

Note : You will need to update your agents after installing this build
Read the rest of this entry »

Posted in Continua CI, Continuous Integration, Development, Software Development | Leave a Comment »

Continua CI Version 1.8 History – the new features

Posted by jpluimers on 2016/04/14

A new version 1.8 of Continua CI was released earlier this month.

The most interesting tid-bits are at the bottom of the version 1.8 history page, so I post them here as I’m lazy.

New Version 1.8 Features

Dashboard Filtering

We’ve added a new filter box to the dashboard so you can quickly find the configuration that you are looking for as you type.

Shared Resources

You can now limit the number of builds or stages which can access the same named shared resource concurrently. This can be useful if you wish to restrict the number of times a particular tool is run due to a license or memory limit, or to prevent concurrency issues with multiple build stages simultaneously writing to the same file, folder or network resource.

Shared resources can be associated with the server or an agent in the Administration pages. They can have a quota or multiple labelled quotas. Builds can be set up to require server shared resource locks in the Configuration Conditions. Stages can be setup to require agent or server shared resource locks in a new Shared Resource Locks tab on the Stage Options dialog.

Shared resource locks are automatically released at the end of the build or stage which acquired the lock.

Requeue Build

A new Requeue button has been added to the Build view page. This allows you to requeue an existing build using the same changesets, variables and queue options. The build will run for the latest configuration with any changes to stage actions, repositories etc.

A “Build Requeue Options” menu item opens dialog allowing you to change priority, comment and variables before requeuing the build.

Persist Build Variables

Continua CI takes a copy of configuration and project variables at the start of each build. Any changes to these build variables are discarded when the build finishes and cannot be used by other builds. A new Persist Build Variable build event handler allows you to store the value of the build variables as the default value of the configuration variable. The next build will then pick up the revised value for the build variable.

You can specify which build event triggers the variable persistence. You can also specify that the variable should not be persisted if the configuration variable was modified since a particular event. This is important as Continua allows multiple builds to run concurrently and you may otherwise get unpredictable results. We also recommended using shared resource locks in conjunction with this feature with prevent concurrency issues.

Additional Improvements

  • Variable prompt ordering. Variables now have a display order property allowing you to specify the order of variable prompts on the Queue Options dialog.
  • Clone buttons for Triggers, Repositories and Build Event Handlers.
  • Configuration Conditions can now be disabled.
  • Cake build action.

Note : You will need to update your agents after upgrading the server to this build.

Source: Version 1.8 History | Continua CI

–jeroen

Posted in Continua CI, Continuous Integration, Development, Software Development | Leave a Comment »

nunit – How can I view .NET trace logs in TeamCity? – Stack Overflow

Posted by jpluimers on 2016/02/23

This indeed works very well:

All console output is shown in the build log.

So when you need more context on tests that succeed, you can just output them on the Console.

A practical use: testing the sending of SMS messages over HTTPS where the intermediate proxy can change and was giving different effects.

Logging the actual proxy used correlated some run-time findings. Based on that we could write better tests.

–jeroen

via: nunit – How can I view .NET trace logs in TeamCity? – Stack Overflow.

Posted in .NET, Agile, C#, Continuous Integration, Development, MSTest, Software Development, TeamCity, Testing.NET, Unit Testing, VSTest | Leave a Comment »

Continua CI: viewing events (errors) for a certain repository #continuaci @FinalBuilder

Posted by jpluimers on 2015/12/09

Somehow this isn’t linked logically from the UI, so here are two sets of steps to get there:

From the “Event log”

  1. Go to the “Event Log” page on your Continua CI server; for my server that is https://continuaci.pluimers.com/administration/events.
  2. Click on any repository name (in my case DUnitX) and note the GUID at the end of the URL: https://continuaci.pluimers.com/administration/ci/repositories/index/94c6f27d-20a4-4f53-a81c-94f863db248d
  3. Append index and that GUID to the first URL: https://continuaci.pluimers.com/administration/events/index/94c6f27d-20a4-4f53-a81c-94f863db248d

From the “Source Repositories”

  1. Go to the “Source Repositories” URL on your Continua CI server; for my server that is https://continuaci.pluimers.com/administration/ci/repositories
  2. Click on the word “Error” or red cross (sometimes you can click only one of them) in front of any failing repository: https://continuaci.pluimers.com/administration/events/index/94c6f27d-20a4-4f53-a81c-94f863db248d

The second has the drawback that you can only see events for repositories that are currently in error, not any repository that has ever been in error.

So maybe I was doing something stupid and maybe there is a far easier way, but these work (:

–jeroen

Posted in Continua CI, Continuous Integration, Development, Software Development | Leave a Comment »

Things I Wish I’d Known Earlier | Dr Dobb’s

Posted by jpluimers on 2015/06/03

Like regular life, a programmer’s life is constant learning. And sometimes you’d wish you had known things earlier.

A few quotes from the article:

Test constantly while coding. Personally, I think the single most important contribution of the Agile movement to programming is communicating the value of developer testing (generally, unit testing). I am not an advocate of TDD and feel that many of the critiques directed at it are valid. But I am a passionate believer in unit testing. Of all the practices here, this is the one that would have served me best in my salad days. The ability to check in code knowing that it’s unlikely to contain silly errors and overlooked conditions allows me to have a much clearer idea of what progress I’ve made. I don’t have to worry nearly as much that there is still an extended debugging cycle of unknown length ahead of me. I now compile with the expectation the code will work the first time, rather than entertaining the fond hope that it might.

Fully automate the pipeline. This seems like unremarkable advice. But it got me to continuous delivery before that concept had a name. I automated build, test, deploy. I also automated updates to the website, to the Javadocs, to just about everything I could possibly update as part of the regular build. While this took a lot of time to write out (using Ant), the payoffs are continual. By having automated everything (well, except for some manual tests) I can build with high confidence in the generated software, even if a given feature is incomplete. I don’t worry at all about fragility. In the future, I expect to automate things even more: I want to write more scripts that simulate all the possible installation options and make sure they all work correctly or provide accurate error messages. Right now, I’m pretty sure they do, but I don’t know for certain because of the absence of this step from the automated pipeline.

–jeroen

via: Things I Wish I’d Known Earlier | Dr Dobb’s.

Posted in Agile, Continua CI, Continuous Integration, CruiseControl.net, Development, msbuild, Software Development, Testing, Unit Testing | 2 Comments »

« Previous Entries
Next Entries »