As noted on most of my recent forum posts - we’re running 100% of our deployment logic via FinalBuilder 8 project files through Continua CI’s “FinalBuilder” action.
The user interactions that control which branch the FB8 is set to deploy from - are communicated from Continua CI input variable forms to FinalBuilder variables passed from CCI to FB8 during runtime.
The problem is:
Since there is no “Source Code” repository attached to anything in the Continua CI projects,
and the only repository attached is the DevOps repository that is required to be attached because it is the repository holding the FB8 project files being used in the continua CI projects -
The build “Code Changes” (under build details tab or build changes tab) - is dervived from this DevOps repository latest commits.
and obviously these changes do not reflect anything that is actually related to the build.
I suspect having these DevOps Changes with their commit messages show in the build details page would be confusing and maybe some what annoying for our developers who will use CCI for their work.
So, I must ask: Is there a way to edit/delete/add Code changes for builds?
There’s no way to submit code changes to Continua CI from FinalBuilder and we don’t currently have plans to implement this.
Why not add your build repositories to Continua CI? You could then either: use the files checked out by Continua CI and simplify your FinalBuiilder project; or uncheck the “Checkout files to workspace” option - in which case the changes will still be added to database.
How are you currently triggering your builds? The main advantage of using Continua CI repositories is that you can trigger a build on a commit to the project source code. This is the essence of continuous integration.
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
You can then access the repository selections using expression objects. Use $Source.RepoName.Branch$ for the selected branch, or $Source.RepoName.Tag$ for the selected tag.
You can also access details of the changeset which gets associated with the build. Use $Source.RepoName.BuiltChangeset.RepositoryChangeId$ for the revision or commit hash.
These values can be sent to the FinalBuilder action via the Variables tab, and used in your git/svn actions.
What you are requesting is backward to the way CI works. We could possibly have some sort of “Register Changesets” action, which allows you to submit a set of changesets from a file, or from FB action results, to the Continua CI database. This, however, would be a substantial piece of work, with potential for conflict with existing functionally. We have a lot of features to work on which we consider to be of higher priority. Note that one of these is to allow selection of commit id, in addition to branch and tag name, in the Queue options dialog.
That’s great news!
Once the commit id selection feature is introduced and we’ll be able to select either a branch name or a commit id - I will modify our projects to use these fields as you suggested, and modify the logic so that we’d send this information to FB8, instead of our custom form variables we have now.
Do you guys have an estimate on when this feature will be released?
If these fields can have their auto-complete still, AND allow free text input that I can later read from a variable ( $Source.RepoName.FreeInput$)
It will allow our developers to use the nicer input (with branch name auto complete)
AND it will allow our FB8 projects to utilize these values (because I will pass this variable to them as input)
If you do not wish to allow free input to these fields in general - please consider allowing it via a custom flag on the application level (for example, only if AllowFeeRepositoryInput=True is set in the application level variables)
Sorry, this is not something we can consider. This field is used to select the changesets to associate with the build and is core to the operation of Continua CI. I don’t understand why you would want to enter a value that is not a branch here? Why not use a separate variable? Perhaps you could share more details about your use case?
That was just a thought based on what you wrote earlier in this thread.
A separate variable will do just fine as well.
We currently use a custom variable - that is manually populated in the variable input form when starting a build.
The only thing I would like to solve here - is the confusion created when our developers see the default branch selection inputs in the queue options form.
As you can see, we have “Input_GitCommitId” variable available for input
We pass this value onwards to FB8 which has all the internal logic to build what it was told via this input form.
Alas - having the same fields above is confusing, so:
If we could use a built in field (with the added auto completion feature, which is very comfortable for our developers) and pass the values in this field to FB8 - it will feel much more natural and comfortable for our developers.
I only requested that the existing fields support “free text” because our FB8 projects support getting either a branch name or a specific git commit id - so we’d like to keep this support while using CCI’s built in options (with all their added values) for this input instead of using a custom variable (without auto complete) for this input.
Eventually, we will include an input for entering the commit id for each repository. For now, I would suggest making the ‘Input_GitCommitId’ not a required field and describing it as an override e.g. “Enter a commit id to override the branch for (RepoName) repository”. You can then use logic statements in your FB project to choose whether to use $Source.RepoName.Branch$ in actions if %Input_GitCommitId% is empty.
