...
(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 FinalBuidler Server and Hudson, Continua manages the 'getting' of your source code. Primarily this is so that using multiple build agents is quick and safe. 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.
Caches
Continua maintains several caches of your source code: one on the Server and one of each Agent. When Continua detects a new commit/check-in/changeset in your repository, it updates the Server cache, then each agent updates its cache from the server. This means that when it's time to run a build the source is most likely already on the Agent.
Building the right codebase
The cache isn't just a bunch of files - it is "version controlled". This makes it easy for us to get the right version of the source to build. For example, lets say you have a Repository Trigger with a quiet period of 1 minute (that is, the build will wait 1 mintue minute after its triggered to see if any other changes come in)
- new commit (Change1)
...
- is detected, which queues up a new build.
- just after the quiet period has ended, (and the build is just starting) a new change (Change2) is detected in your repository, which is automatically sync'd to all of the agents.
...
- now your build starts running on an agent
Change2 is in the agent, it doesn't simply get what's in the cache: it gets 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.
This also allows us to run stages on different agents. For example, your Build stage might run on Agent1 and your Installer stage on Agent2. When the Installer stage gets to Agent2, it gets the same version of the cache that was used for the Build stage. Without this versioned cache, we would need to run every stage on the same Agent , to ensure that the correct source was build used. We also re-apply and 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.
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.
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, as mentioned above, we track files that are changed during the build and re-apply them.
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, 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.