I'm trying to set up a way so that during my nightly automated build, even if the action group had the 'enabled' property unchecked, I want to run the step.
Looking into the scripts, there is no action property for enabled, so I don't believe that I can set enabled = true there. And setting skipaction to false doesn't seem to help.
Any suggestions on how I can force an action group that is enabled false to run, or to cause the enabled to be set to true for a specific action?
The reason I want to do this is that sometimes during the daily builds people sometimes turn steps on/off, but then forget to set them back to enabled so when the nightly build rus it doens't execute those steps.
You cannot programmatically change the Enabled property of actions. A solution to this is to make use of the flow control actions and variables to control which actions are run during a build, that way people do not need to mess with the enabled state of action groups. You can also use the Prompt for Variables action (or one of the other actions in the interactive category) to have people specify which parts of the build process they want to run. This is how our build process works here, if it is run interactively we are prompted for some info. If it runs via a schedule (or from FBServer) then it uses some defaults and doesn’t prompt. We never mess with the enabled state of action groups.
Another thing to consider is keeping your FinalBuilder projects under version control, and keeping the project file read only when not checked out. That makes it a more conscious decision to change the enabled state of actions.
We already use flow control and prompt for variables in a number of places, I guess I was just looking for a fail safe way of enforcing that certain steps were always being ran - thus the desire to progmatically change the enabled status. I'll have to do some rework on the scripts, see if I can't come up with a different solution.
PS Substute angle brackets for the square brackets above. There is something seriously whacked out about the character escaping in this forum software. It seems to be de-escaping twice or something, so that even typing ampersand-lt-semicolon gets interpreted as a tag. And strangest of all, it ended up interpreting the above string as a tag whose text was the escaped version of the tag! Argh…
Um, I don’t know if you were kidding, Steve, but this is not a good idea at all.
It would theoretically be possible to use XPath to manually edit the project file to ensure that certain action groups were enabled (maybe before calling Include Project), but this is far from an elegant solution.
Regards,
Angus
EDIT: Now steve has corrected his post to show the extended XML syntax (before the post just said to replace False with True), this will work acceptably to enable all actions in the project. I still wouldn’t recommend doing things this way, if there is a possible alternative.
Heh, not sure if you saw the dodgy version of my post where it looked like I was replacing all False’s with True’s. No, I didn’t mean that.
Steve (edit - had my trues and falses around the wrong way. Boy, doesn’t it get confusing when you edit your posts after someone has already replied… )
Why is this not an elegant solution? I sort of presumed that one of the reasons you guys chose raw XML as the save format was to allow people to perform this kind of manipulation on the project files? There are no introspection or self-modifying actions in FB (thank god!) so that would be the only way to do it. Fortunately I’ve never needed to do it…
I think that, for the reasons Vincent said, it’s definitely better to use flow control, execute conditions, or the SkipAction parameter, to avoid the need to enable and disable actions on the fly.
Automatically munging the XML like this can eventually lead to problems. Consider:
- When you actually do want to disable some portion of the build process semi-permanently (ie you create a new action group to replace an old one, so you disable the old one but don’t delete it yet.) - When you want to put the project file into source control and not gain a revision every time its changed automatically. - When the “child” project is open in the FinalBuilder IDE and the “parent” tries to edit it. - If we change the file format (not likely, but possible.) - If the XML is written out with a non-standard whitespace configuration. - The fact that, unlike flow control and skipped actions, disabled actions are not logged when the build runs.
I’d recommend doing it once to make a wide-ranging change which is hard to implement in the IDE, just not as part of a regular process. There should be a neater way to do it.
Yeah, I agree with most or all of that. However, the situation where you effectively don’t trust the other editors of your project file is a pretty interesting problem to solve in general
Posted By Angus Gratton on 23 Apr 2007 6:36 PM > Is there a particular scenario where a certain Action Group is likely > to be disabled by someone? Can you work around that?
There are 2-3 of us that are routinely using the build scripts, our scripts do many things… check out source, build 60 exe’s, a dozen or so DLL’s, regenerate 20+ HTML files, create .CAB and JAR files, codesign them, copy the build to 1-5 test servers, and sometimes we generate install shield projects…
Sometimes one of us has to do a partial build and depending on actions things may get disabled. Being able force them all back to enabled when the nightly build runs would help out.
I ended up creating a cloned main project that is just for the automated build, and have it use the same child projects (we have around 20 we use) as the manual main project does. It would have been easier to have set the action groups enabled, but I was able to achive the same thing this way. It does make for more work having to keep the 2 projects in sync though.
For the sake of maintainability, I strongly recommend moving to a model where variables control the build process.
I would recommend setting up a master project which queries for which portions of the build to enable (using the Prompt for Variables (Enhanced) action.) Based on that configuration, the master project can use “Include Project” actions to run separate child projects which contain each modular section of the build. Most FinalBuilder users who build large and complex systems do so in this way (some have over a hundred project files.)
You can use an if/then action to check the %ISAUTOBUILD% variable, for when the project is run automatically for the nightly build (it can skip the prompt and set all of the options to “true”.)
Let me know if you’d like me to mock up an example project.
An other way to solve this is to use source control. You could use a “NightlyBuild.fb” script on the the buildserver. The only thing it does is getting the “ScriptThatDoesAllTheWork.fb” from sourcecontrol, and run it. For on the fly builds, you can just change anything you want in the STDATW.fb, as long as you don’t check the changes back in. Jaap.
