At the start of the year, all of our build processes were finally CI friendly and wired up to Jenkins. Now, whenever a commit is made to our SVN repository, the relevant products are built, tested, and deployment artefacts produced.
As well as building the setup programs our users ultimately install, the build process now also extracts all the files and tests them for dependency errors, using a slightly more improved version of a sample I posted some years ago. This will hopefully avoid future issues where we introduce a new dependency then forget to update setup with it, as has happened in the past.
Although a lot of our code is still woefully lacking in available tests (and the UI themselves are never tested, save manually), what tests do exist are ran for each build.
If any tests or deployment checks fail, the build itself is flagged as failed and no artefacts are produced.
Therefore if artefacts are produced, there is some surety that it can be expected to run without issue, which slightly lessens the burden of deploying the releases - usually an XP or Vista virtual machine is fired up and a manual smoke test is performed on the basics, plus checking any new functionality.
With these safeguards in place, and concious that sometimes there is quite a delay between official releases, we've decided to have the latest CI build automatically uploaded to cyotek.com each day. Not really nightly builds, but the term is easily recognisable and so will do.
These builds are provided AS-IS and are not supported by Cyotek.
Although I want to make these builds available for users with problems with existing releases, I do want to stress the point `- these builds are created and uploaded via a fully automated process and have not been reviewed or vetted by anyone at Cyotek.
In other words, while our basic checks will pick up some issues (and we will continue to iterate and improve on this process), there are no guarantees that the code is fit for purpose. For example, we could have introduced a bug in CopyTools where it goes on a rampage and deletes files instead of copying them. In theory, that shouldn't happen as there are actually quite a lot of tests around this functionality. But, the point remains - it could and we wouldn't know about it.
So please, if you make use of nightly builds to work around a bug in WebCopy, or CopyTools, or any of our other products note that the builds are provided AS-IS, and have no warranty.
It is also possible that functionality added in a nightly build could subsequently be removed, which could lead to its own set of problems, for example incompatible file formats.
If you haven't been scared off yet, automated builds will appear in a new Nightly Builds section of the product's Downloads page. Not all products will have had nightly builds switched on at the time of posting as we make final checks on the updated build processes.
Although most commits do include notes in the changes in the commit, they aren't for public consumption and wouldn't make a lot of sense if posted verbatim either. As CI builds are triggered after each check-in, this could be for the most trivial of reasons, which is why only the last daily build will be uploaded.
However, we tend to record pending changes in the Upcoming Changes section of each product, so this should be the first place to stop when checking what goodies a nightly build may or may not have.
Nightly builds are currently invisible to release checks and won't be included. When a new stable release is found, a nightly build would detect that as usual, but normal releases cannot detect nightlies.
Sorry, the files are provided AS-IS. Remember, no human has been involved with the production and deployment of these builds, so potentially issues could be present.
You can always report issues with nightly builds on the forums.
- 2016-03-06 - First published
- 2020-11-23 - Updated formatting