Feature request - automatically build module.ini file when doing build clean

HFCDev · 2024-10-23T13:28:02+00:00

There was an error rendering this rich post.

Hi,

I am recently faced with a client requirement to embed a build number/code into my module ini file. I know that yeah, the webmodule object in Oscript has the '0 DumpModuleConfigToFile' function, and that we can override it to add our own tags, but what I really want is a way to have build clean regenerate the module.ini when we rebuild the module, ideally with a subclass that allows us to specify additional name=value pairs (and their section) to go into the module.ini file.

The goal is to automate this annotation that is required for the module so that product management and support know exactly what version of a module they have in their hands, as well as to automate adding items to the module.ini that may change with each subsequent build.

At the very least, the existing '0 DumpModuleConfigToFile' should be refactored so that we can override a subclass to add sections we want included additionally in the module.ini instead of having to override the entire script. Given the way that OT Dev has a tendancy to update key bits of code which 3rd party developers may orphan, this only makes sense.

-Hugh Ferguson

Find more posts tagged with

OScript

Comments

appuq

I do it manually because of this reason . The CreateAmodule.lxe which was the go-to module in our old builder days it came out of the Oscript community. if OT won't listen…My guess is OT does not want Oscript 3rd party devs…

HFCDev

As I think about it, the best thing would be if we could have a hook into the build clean, that is, when Build Clean is invoked from CSIDE menu, that it would call a feature in every WebModule object in modules that are in the source directory that by default is empty, but is a place we could do our own thing, such as write into placeholders in module files like module.ini. In that case, ideally there would be a RunBuildCleanPre() and RunBuildCleanPost() so we could do pre/post operations.

Mind you, if the end goal of OT is to keep us 3rd party developers out, then I can see them not doing this or anything remotely like this.

-Hugh

Dave Carpeneto

Hi Hugh - once the ini file is in your workspace: there's nothing in CSIDE that will re-generate that file from information in the server. One of CSIDE's core design intentions was to keep all source-like stuff in the workspace.

If you're looking to automate this: my initial thought is to set up something that runs on the command line which (A) updates the ini file with the build number / whatever you're looking to add, then (B) builds the module via OBuild . Alternately if you're doing this via Eclipse: I'd be interested in learning more about how the build # is getting generated. Note that there have been a fair number of … oddities … exposed in the CSIDE build process for quite some time. The 25.1 release (hopefully January) squashes every oddness that I could find.

Apart from initial module creation / module import: there really isn't much functionality in CSIDE to bring data from the server to the workspace.

if the end goal of OT is to keep us 3rd party developers out

I can assure you that's not the case :-)

David Henshaw

Hi @Dave Carpeneto,

If I can expand on hugh's original and subsequent posts here…..

For us (me!) the end-goal is to be able to define a build pipeline that utilises OBuild to generate the module.

The "nuisance factor" here is that developers have to both update features in each solution's WebModule object and generate (manually) the corresponding INI file that corresponds to these.

Fundamentally, this means the source has (at least) two items reflecting the same information and needing to be maintained in parallel.

Why not simply have the CSIDE/OBuild process generate the module's INI file as part of the build?

Regards,

David.

Dave Carpeneto

The "nuisance factor" here is that developers have to both update features in each solution's WebModule object and generate (manually) the corresponding INI file that corresponds to these.

Are you updating the objects in your workspace (OScript Explorer), or on the server directly (Module Explorer)?

If it's the workspace (which is where we are kinda expect updates to happen): is updating the workspace ini file an issue? I get the "copying / pasting duplicate info feels gross" factor, but I'd guess that'd be less painful than regenerating the ini on the server & then copying it back to your workspace 🤷‍♀️

Why not simply have the CSIDE/OBuild process generate the module's INI file as part of the build?

I guess maybe we could? However if we did add a call to this in the server-side of things: CSIDE's "the workspace rules reality" mindset really doesn't lend itself to copying files from the server post-build. We generate & copy the ini file to the workspace when a module is created or imported, same as the objects & such. Outside of that I don't think there's anywhere we move anything from the server to the workspace.

Thanks for the clarification / sorry for not understanding the complaint fully / hope I'm still not misunderstanding things 😉

HFCDev

I will explain the use case I have in a bit more detail. First our notion of build is only loosely coupled with a git commit (I have taken to creating a tag in git that represents all that is in a build I'm sending to QA). The development process has evolved since 2010 when we were still using Builder. At the time, we created a build number feature in the WebModule object (the one which ultimately generates the ini file with a script that is part of the original WebModule object everyone orphans), and we maintain a String feature with the build history (lately I've been truncating it after every release and keeping the old build history in git). A "build" really is the state of the module between QA cycles.

Up until recently, this satisfied our needs just fine. We had orphaned from WEBLL::IndexCallback::LivelinkIndexCallback used to display information about version and build info on the About Content Server page. That was fine until product management/QA came back and said they wanted to be able to know what build they had just by looking at the module zip file. That is where the requirement to write the build number into the ini file came from.

If you do a build clean it doesn't touch your src ini file. If you run the 0 DumpModuleCOnfigToFile, it refreshes the one in your module directory. I suppose I could just exclude the ini file in src from git and make the one that gets generated by 0 DumpModuleConfigFile() the source of truth, but once again, I need to do both Build Clean and the Dump of the module config file. The fewer places we have to muck about, the less chance of mistakes. Ultimately, that's why there is so much interest in build automation.

HFCDev

PS one solution that would be kind of cool is if the ini build from src could do a tag replacement. That is, if we could write in the src ini file something like buildnumber=[OSPACENAME::WebModule.fBuildNumber /] and it takes the bracketed content from the source file at the time of building.

I guess this is a collision between the old builder world and the brave new world of CSIDE. Remember the good ole days when we used to edit Ospaces directly in memory :)