As we prepare to move from our current FBServer + FB7 to CCI+FB8 combo
We’d first like the new combo to work EXACTLY the same, meaning:
CCI will function a Web-UI fronted that allows developers to run the FB8 projects that orchestrate our builds.
So most build triggers will be manual: Developer clicking “Play” button on the relevant project/configuration, populates an input form with some information and then finally “Queue build”.
(some other small projects are triggered based on schedules or other project completion)
We do plan on slowly modifying the logic and simplifying things if possible and extending our usage of Continua CI’s features (Integrate unit testing, possibly port some of our FB8 flows to CCI, and build some sort of a modern CI/CD pipeline)
But that will all happen only in the coming weeks/months after we migrate our existing setup successfully.
I have added our main code repository to Continua CI as you suggested (unchecked the “Checkout files to workspace” option).
At first it seemed that manually triggered builds are waiting in queue due to “no new change sets in this repository” but I guess that was just when the repository was initially cloned on the server and caches being updated.
I now see that code change sets from the main code repository are included / listed in the builds (In addition to change sets from the DevOps repo that’s holding the FB8 projects, and are not relevant for developers)
But: due to how things work with our FB8 flows - this can be very confusing, consider the following flow (which is our most common one):
A developer manually triggers a build on CCI, using variable input form, he specifies a git branch name or a git commit id to build from - these options are passed to FB8 project file which has the internal logic to fetch the exact branch head or commit id and build from it assign it with a matching version number, etc’ etc’.
(Again, this all happens on the workstation running the agent that is running the FB8 project, this workstation has a directory structure on it, external to the Continua CI agent shared work space, this directory structure with cloned repositories in it - is all managed via the FB8 project logic)
And while the FB8 builds from commit XYZ which was manually specified -
Continua CI will display the most recent change-set from the repository as it is configured in the CCI repository settings. (most typically: master’s HEAD)
So the developer specified XYZ commit id from branch B but now sees the build details and the associated change set that is specified there is actually master’s HEAD
That’s why I asked if it is possible to somehow overwrite this value - so we can use the correct values that the FB8 project used (same thing we do with build version for example - we overwrite Continua CI’s build version information with relevant information passed from the underlying FB8 project).