In the Final Builder’s Menu, there is a command to “Edit Project Information”.
You can find it my clicking on the “Project” menu and selecting “Edit Project Information”.
I'm interested in how a project script at build time can set and get these values. This is because I want to version control my build scripts.
I would like to pull the most recent build script from source control when starting a new build. But in the case of performing a redo of an older build I would then use the build script which was used at that time. So for logging and double checking purposes I would like the script to be able to know what version of the build script is being run and compare that version with the latest stored in source control.
Will I be forced to use a variable to keep track of the build script version? I would rather not as that can be changed by whatever or whoever calls the build script. That is what led me to look at the “Project Information” details.
Any insight into this topic specifically or regarding build script versioning in general would be greatly appreciated.
The Project Information (author/notes) is not designed to do what you are trying to do.
IMHO, the best option would be to use a bootstrap project, which gets the source code and associated FB project from version control, and then runs the FBProject that was in version control. This is how we do our builds here, the bootstrap project rarely changes, all it knows is how to do a get from vcs (source and main fb project), and then uses the include project action to run the fbproject we got from vcs. That way the fb project that was used to build a revision in the vcs is always known, as it’s in the same vcs repository.
Hi Vincent, thank you very kindly for your quick response.
Yes, that is a very commonly used idea and I have done it that way in the past on more than one occasion, using the bootstrap program to pull the latest and greatest build script out of source control prior to executing it.
But doesn’t that negate the FB Server’s propagation of variables and their descriptions coming dynamically from the real build script? I found that feature of the FB Server to be extremely convenient. Currently in my FB Server I am able to pick and choose among more than 15 purposefully exposed variables to change the flavor of my build runs. I can change things like who to put on the email notification, what type of build is to be delivered (test, QA, RC, Release), what drive to use for the sandbox, and much more. Whatever variables are not specified in the FB Server's Console, will of course use the script defaults. So how would you maintain that FB Server feature if you insert a bootstrap program in the middle?
Also, why the bootstrap program at all? Shouldn’t the FB Server have a checkbox and 2 fields which would allow the FB Script to be pulled from a location in source control prior to executing it, and to pull it based on a revision or the head revision? A source control CI trigger feature already exists in the FB Server, so adding something to pull the script to execute should be fairly simple I would think.
But back to my original post, for double checking purposes, clarity, and for when we want to run a re-build of something older (i.e. for investigation purposes) it would be nice to have the build script versioned and know the version of itself. My idea for that was to have our build scripts treated like any other kind of development effort. They should be promoted to a release line and built just like any other kind of developed software, although since the FB scripts do not require compiliation or linking, the building of them would simply make them available for primetime use and version them – versioning them somewhere other than a variable (since variables are not as locked down as are file properties and project information dialogs).
I think you misunderstood what I was suggesting. I wasn’t suggesting a bootstrap program, but rather a bootstrap FinalBuilder Project. That bootstrap project only does 2 things :
1) Get the source code and main FB project from VCS - either a specific revision or the latest. 2) Runs the main FB project (using the Include FinalBuilder Project Action).
So FBServer will run the bootstrap project. You can pass variable values from FBServer to the bootstrap project, and from the bootstrap project to the main project. So if you wanted to build against a specific revision of the source, then you would specify the revision in a variable in FBServer (ie using the prompt for variables feature) and use that variable with the version control actions to get that specific revision.
HTH
This is how we run our builds here, and have done so for many years and it works very well.
Thanks you for your reply. I read through the information you provided a few times and actually I did and do understand what you're talking about regarding the FinalBuild bootstrap script. I have done these type of scripts before, using 3GL and 4GL tools both.
But before I go into the bootstrap script further, I'm wondering if we should change the name of this topic's title? It has become more about the mechanisms by which a build script is pulled from source control than ways to keep track of what version of the build script is, or was, used to build software source code, at any given moment in time.
And also, again, before I go into the bootstrap methodology, I do want to kindly mention that it would be nice to be able to contain the version of a build script in the build script itself (without having to do it with a variable) - thus treating the build script itself just like any other developed, tested and released piece of critical software. Of course there's always the check-in (or commit) revision number, but that requires looking at and operating with the source control tool. There are a number of reasons why having the script contain (and obtain programmatically via standard release processes) a version string.
Now onto the bootstrap program. I still see an issue with the FB Server: Certainly you can pass the variables from FB Server side through the bootstrap program and onto the build script. But when you add new variables to your build script, along with default values and description text, how is the description text and default values going to appear in the FB Server console when you use the "Add" or "Edit" variables activity inside the FB Server? I found that feature of the FB Server to be extremely convenient. When I click to see what variables are available in my build script, that I may want to override or set correctly, via the FB Server side "Add Variable" feature, the FB Server lists out all the variable available to me and pops up default values and the description text of the variables (these things are dynamically pulled from the build script). If you insert a bootstrap script in the middle, don't you lose that "Sneak Preview" capability which is so powerful and convenient?
And again, what about the need fot the bootstrap program at all - which I mentioned in my above post? ...why the bootstrap program at all? Shouldn’t the FB Server have a checkbox and 2 fields which would allow the FB Script to be pulled from a location in source control prior to executing it, and to pull it based on a revision or the head revision? There are other Dashboard CI Server products out there which are designed to help manage build scripts and processes which are much less powerful than the FB Server product is, which have had this feature for quite sometime. Having this capability in the FB Server product would remove the need for a bootstrap program. Is this something which the FB team has thought about?
You are correct, the variables from the main project will not propagate through to the bootstrap project, you would need to define the same variables in the bootstrap project.
As far as changing FBServer to get the project from version control, it is not something we are considering, primarily because we are working on a new CI server that will eventually replace FinalBuilder Server. It’s also technically quite difficult to achieve due to the architecture of FinalBuilder Server (version control support is tied in with triggers), it would require a substantial amount of refactoring to get it to work, multiplied by each version control system supported, and a significant testing effort. We’re spread pretty thin at the moment, working on the next version of FinalBuilder and the new CI server product.
The new CI will not be tied directly to FinalBuilder (ie it can run msbuild, ant, nant etc as well as FinalBuilder), and it will only be able to run build scripts (be they finalbuilder projects or other build scripts) that are included in version control. It will not automatically know about the variables in your FinalBuilder Project, however we will have the ability to import the variable definitions from a finalbuilder project, and it’s variables will be passed to FinalBuilder at runtime. It’s not quite as tight as FinalBuilder Server in that regard, however it does have a lot more functionality in other areas, all of which are in response to requests to users. We’re still working flat out to get the product ready for beta, which I hope will happen next month some time.