i want to better understand what a changeset in ContinuaCI is. I've checked the docs and searched the forum, but wasn't able to find specific information, other than repository usage in general.
In CCI's UI i covered the following configurations:
Configuration/Details/Options Default Associated Changesets [Most recent changesets|All changesets since last successful build] The default changeset association for builds started with this configuration.
Configuration/Triggers/Repository Associate Changesets [Latest|All since last successful build] Associate only the latest changeset from non-triggering repositories or associate all changesets from non-triggering repositories that have been committed since the last successful build.
Questions
How can "most recent" be determined exactly?
What changesets are included for "since last successful build", when changesets belong to different branches?
Why is "most recent" the default?
What is the effect of "latest changeset|all changesets" when a build is started manually for a triggering repository?
How does "Latest Changeset" be distinguished from "most recent changesets"?
How does a changeset distinguish from a Git commit?
What files does a changeset contain?
What is my intention?
I want a build to reflect a Git commit! A Git commit does represent a snapshot of all files in the repository. How can i achieve this with ContinuaCI?
A changeset is the list of differences between two successive versions in the repository. As such it is analogous to a commit, or revision. The term 'changeset' is used to be independant of the terminology used for each type of repository.
Responses to your questions:
Generally changesets are ordered by the creation date, the latest being the most recent. Git changesets (or commits) are slightly different as they are ordered topographically using git log --top-order. The most recent, or latest, in this case being the first in this log order.
The "All since last successful build" option for the "Associated Changesets" dropdown only includes changesets on the same branch as the changeset that we are building.
Continua CI is generally set up trigger builds for each new changeset on a branch as it is detected. Building the most recent changeset seems like an appropriate default. As you have seen, you can change the default for each configuration in the details tab of the configuration wizard.
Selecting the option "All since last successful build" has no effect on the build. A snapshot of files at the latest changeset revision is always built. This option controls which changesets are listed on the "Changes" tab of the Build view. When "All since last successful build" is selected, then more changesets are displayed in this view.
There is no difference between the latest changeset and the most recent changeset. We should probably be more consistent with our terminology here.
There is no difference between a changeset and git commit.
When Continua CI builds a changeset, it includes all files at the particular commit hash or revision, not just the differences. Unless, of course, you use any filtering options to narrow down the files included. With git repositories, we basically run 'git checkout' for each commit hash.
Continua CI does already build a snapshot of all the files in the repository at a particular commit.
Currently you can only select a branch or a tag, when starting a build. Therefore, you can only build the head commit of a branch or a tagged commit. The only way to build an earlier commit is to rebuild an existing build on that commit. As this is continuous integration, the chosen feature set is based on the use case of triggering builds on every changeset as it is added to the repository.
We plan to implement functionally to allow you to select an old changeset (or commit, or revision) to build at some point in the future, once we have decided on a suitable interface that works for multiple repositories and does not require users to enter a long hash to pick a changeset.
first of all thanks for your detailed reply. I am assured now, that my builds will include the correct source. Still i think the UI is confusing.
What for is the configuration to associate "all changesets since last successfull build", when actually HEAD of a selected branch/tag will be built. Does it actually have an effect on the selection of the changeset used for the build? Or else, does it control the view of the "Changes" only?
What for do i need "Configuration/Details/Options" after all?
In "Configuration/Triggers/Repository" there is a hint "Associate only the latest changeset from non-triggering repositories or associate all changesets from non-triggering repositories that have been committed since the last successful build.". My understanding of this is, to build changesets only, if they were committed after the last successfull build. If so a boolean checkbox could make things easier to understand.
All the Associate Changesets selections control the view of the "Changes" tab on the build view only. They have no effect on what gets built.
The Default Associate Changesets option selected on the configuration Details page defines the default Associate Changesets option shown in the Queue Options dialog when you start a build. It is also the option used when you run a Quick Start Build. The Associate Changesets selection for the Repository Trigger is the option used when a build is started from a trigger. They are all they same thing - they control the view of the "Changes" tab on the build view.
We could replace this with a single filter on "Changes" tab and may do that in the future. Meanwhile we'll add some text to the field descriptions to clarify what they are for.
We could replace this with a single filter on "Changes" tab and may do that in the future. Meanwhile we'll add some text to the field descriptions to clarify what they are for.
Let's go for it :) This will clarify the matter and make configurations easier too.