Is there a way to modify "Code changes" assigned to builds?

[ktopaz]

Hi Guys,

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?

Thanks!

[Sparky (Dave Sparks)]

Hi @ktopaz,

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.

[ktopaz]

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.

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.

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).

[Sparky (Dave Sparks)]

Hi @ktopaz ,

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’.

If you set up your repositories to monitor all branches or branches by pattern, then a branch/tag selection control is displayed in the Queue Options dialog. e.g.

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.

[ktopaz]

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?

Thanks again!

[Sparky (Dave Sparks)]

Sorry, we’re a small team juggling a lot of balls. We can’t provide time estimates for features.