Repositories
A Repository repository in Continua CI is simply a wrapper around reference to an external repository which Version Control System (VCS) that provides a way for Continua CI to interact with that repositoryVCS. Adding a repository to Continua a repository and assigning it to a Configuration allows the user to make use of that repositoriesthe VCS's content in other parts of Continua . For example, adding a repository and assigning it to a Configuration allows that Configuration to use the content in Stages & Actions. Once a repository has been assigned to a Configuration, its change sets are tracked and displayed on various pages. All change sets for a Configuration's repository will be shown on the Configurations change set page. All change sets that trigger a build or were last added since the previous build will be shown on the build's change set page. You also have the ability to see your own change sets if you've linked your Continua account to your repositories' account via the My Changes setting. When configuring a repository, you also have the ability to link it to an Issue Connectors which basically allows you to link certain repository check-ins CI. Some examples of using a repository in Continua CI include:
- Automatically trigger a build whenever a check-in occurs in a tracked VCS.
- Referencing components of the VCS in build actions.
- Monitor and record changes in the repository. These include changesets that triggered a build or changesets that have been added since the previous build was run.
- Show changesets that were committed by the current user. For a user to correctly view their own changes, they will first need to configure their Repository User Mappings.
- Link a repository to an Issue Connector. This allows you to automatically link repository check-in comments to an issue in your issue tracking system.
(Something about Global, Project, Config repos????)
Triggers
A Trigger is a Continua feature that waits for certain events to occur, when they occur the Configuration the trigger is assigned to is executed. A trigger can be setup to execute the Configuration when a check in is made to a specified repository or at a certain period in time.
Under the hood
Unlike other CI servers like FinalBuilder Server and Hudson, Continua manages the 'getting' of your source code. Primarily this is so that it is quick and safe to use multiple build agents. You don't need to understand how it works under the hood, but it can be helpful if you're wondering why Continua does things in a certain way.
Repository Caches
Unlike some other continuous integration servers like FinalBuilder Server, Continua CI manages the retrieval of your source code. When you create a repository in Continua CI, it points the Continua server to your VCS. The polling frequency of each repository can be set to specify how often the Continua server polls the VCS for changes.
...
...
...
...
...
Building the right
...
code base
The cache isn't just a bunch of files - it is versioned. This makes it easy for us to get the right version of the source to build.
When a build is initialised, either manually or from a trigger, Continua will check if there are any new changesets for each repository in the configuration and, if it finds any, update the repository cache.
At this point the latest changeset for each repository will then be associated with the build. Continua will then try to reserve an agent to run the first build stage. After this point the build may need to wait for an agent to be available and further changesets may be detected, however all build stages will always use the source code from the latest changeset associated with the build.
For example, lets say you have a Repository Trigger with a quiet period of 1 minute (that is, the build will wait 1 minute after its triggered to see if any other changes come in)no quiet period set. Given the following steps:
- A new commit (Change1) is detected, which queues up a new build.
- just after the quiet period has ended, (and When the build is just starting) , a new change (Change2) is detected in your repository, which is automatically sync'd synchronised to all of the agents.
- now your Your build starts running on an agent.
Change2 is in the agent's cache - but we don't want to build it. We want to build the code that triggered the build. So, we get the version of the cache that contains the most recent changeset associated with the build. In this case, that will be the changeset that triggered the build (Change1). Change2 will have triggered its own build, which will build the version of the source associated with it.
Note if the build is initialised by a Repository Trigger and a quiet period set has been set, Continua will continue to associate any new changesets it detects on the triggering repository with the same branch as the triggering changeset until the quiet period has ended. The build will then continue with each stage using the latest changeset associated with the build before the quiet period ended.
- A new commit (Change1) is detected, which queues up a new build.
- During the quiet period, a new commit (Change2) is detected, and this is added to the changesets associated with the build.
- Just after the quiet period has ended, (and the build is just starting) a new change (Change3) is detected in your repository, which is automatically sync'd to all of the agents.
- Your build starts running on an agent.
We then get the version of the cache that contains the most recent changeset associated with the build. In this case, that will be the last changeset detected during the quiet period (Change2).
...
Build workspace and parallel builds
Each build has its own workspace: a directory that is sync'd between the Continua server and any agents the build runs on. It contains things like a serialized copy of the build's variables, any source files that are changed during the build, any artifacts that are registered, and the build log. When a build is run on an agent, the correct version of the source is copied from the cache into the workspace. Using a copy means that we can run multiple builds of the same stage, at the same time, on the same agent without any conflicts.
Repository Architecture
The diagram below demonstrates the architecture used by Continua CI.
Although a copy of the source is placed in the workspace on the agent, we don't sync this back to the server. The performance cost of moving a potentially large amount of data around for every build is too high. Instead, we re-apply the changes you make to the source during the build. So again, if your Build stage runs on Agent1 and produces a bunch of assemblies, when the Installer stage starts on Agent2 those changes will be re-applied to the source folder, and you can reference them as if you had just build them.