OBuild: OScript commandline build tool

Hi Hany,

I'm bouncing around with joy.....we've been waiting for this for a long time, an eternity in fact :)

What's the ETA on availability, and is there any supporting documentation specific to OBuild and/or known issues that you can share?

Regards,

David Henshaw

Fastman

Thanks Hany.

Your comments noted and understand this is an initial release.

Future term, removal of the need for a deployed and configured xECM/CS instance I'd think will be critical to achieving goals of a CI/CD pipeline. i.e. I've visions of being able to spin the build process up in a docker image.....(perhaps even one that OpenText provide 😉)....and where the docker image is based on the target output platform (i.e. Windows/Unix, in fact, that'd be a handy commandline option also!) and the output is then directed somewhere (e.g. a mounted volume) for consumption.

Will do.

I was on a call earlier today with Juliano Ghisi.....our discussion on this topic goes back a while 😀....and he did give me a brief update at OpenText World a few weeks back.

We'll await availability and then happily feed our comments to you and the team.

Awesome !

Any plans to make the source code available on github ? So we can tweak it for our own builds ?

Thanks,

Pierre

@Darcy_Casselman - question above re OBuild and INI files relates to earlier thread here - Regenerating module from src — OpenText - Forums.

Has anything changed on the module INI front and updating this direct from CSIDE , or better yet OBuild preparing it for you? 🤗

@Stephan Baumann - thanks got it working. Definitely a step in right direction!

For those on this thread from OT, some questions or ideas.

1. The resulting output seems to be a folder for each module, under a "staging" directory. E.g. given a module input of XYZ, a staging\XYZ output would be created, with the ospaces etc under this. The XYZ folder doesn't contain the module number (e.g. XYZ_22_4_0). It would be handy if this were included automatically. (As far as I know, non-OT core modules still require the number in the folder name).
2. Is there an option to specify the platform of the build output - e.g. Windows/Linux. This would be handy so as to reduce need to setup two different OTCS installations and build on each.
3. Does the Content Server installation that OTHOME points to need to be fully functional, or more specifically connected to a database? If I comment out the dftConnection setting in opentext.ini seems that OBuild can still successfully build. That'd be very handy, see next question!
4. In similar vain to question 3 above, whilst we can deploy OTCS using Kubernetes, are there any documented steps or Dockerfiles for deploying solely as a Docker image. Would be very handy to be able to have something like Jenkins spin up the build environment from a defined script.
5. Where a module contains multiple OSpaces, where do OpenText themselves store the Xlate (.properties) files - in the main Ospace, or in the relevant Ospace?
6. It seems OBuild only replicates folders from the source module that are "well known" - e.g. adminhelp, help, html, support. Suppose you have a module that use java libraries and has an ojlib folder, it seems OBuild does not replicate that across. Nor other folders we may have included (e.g. csapplications, samples etc that we bundle with our solutions). Am I missing something here, or are there flags I need to add, or plans to address this?
7. Is there a firm reason why the input module directories need to contain a .INI file for the module? In my view, that would be produced by the build process, based on the .OS file inputs. i.e. let the developers worry about writing code, and updating features in the code, so that they don't have to remember to then run a script manually (to reproduce the INI) before committing changes.

The introduction of OBuild as a CLI tool has significantly simplified our workflow by eliminating the need to rely on Eclipse or GUI for building OScript modules. This change has been instrumental in enabling us to automate our build process and establish a robust CI/CD pipeline. Previously, automating these processes with CSIDE was a challenging task, but OBuild has provided the much-needed solution to this long-standing issue.