OBuild: OScript commandline build tool

Hany Samuel

In 22.4 release, we release our new tool OBuild. This is a CLI tool to build OScript Modules without the need to have Eclipse or GUI. This tool is mainly for third party developers who wish to automate their build process and build a CI/CD pipeline which has been always a challenge if you only use CSIDE. 

We really love you hear from you about your experience using OBuild. OBuild is the result of previous feedback from you. Our customers asked for a tool to automate the build of OScript modules they own. Please create a ticket with Customer Support for CSIDE, and it will be forwarded to us. Also, you can post your questions, suggestions, and feedback on the forum. Your feedback helps us to continously improve our software to meet your expectations.

David Henshaw

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

Hany Samuel

https://forums.opentext.com/forums/developer/discussion/comment/965389#Comment_965389

Hi David,

I am so happy to hear that ! :)

I am not sure of exact dates but it should come out with the 22.4 release which I believe within these days. The documentation is released as section of the CSIDE documentation. This is the first release, so the feedback we get is what will shape the future direction os the tool. For example, the tool depends to work on the existence of OTHOME installed (specified by commandline option --OTHOME ) and configured content server to build against (same as CSIDE). That will require you to install content server on the build machine. We plan to change that (in terms of having cs installed and configured, just have the required dependencies over) but again based on the feedback, we will prioritize that work. Also, the tool currently build a workspace of modules each specified in folder defined by the ini file of module (similar to CSIDE srcmodules folder created in your project). This srcmodules directory is specified by the commandline argument --SRCDIR. unlike CSIDE, OBuild will not change inside the installed content server modules, it distribute the output ready for you in output directory specified by the commandline option --OUT in staging directory that contain the ospaces, weblingo and support files ready for install for you.

a sneak peek of the tool running (it works for both windows and linux)

Never hesitate to reach out if you have any questions or suggestions. I will love to hear back how you find the tool and what you like to see in the future releases :)

Thanks,

Hany

David Henshaw

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.

Hany Samuel

There is a workaround for everything :) just get the tool and see what can be done with it then lets discuss your exact use case and find a suitable workaround and/or feature request :)

This tool is mainly defined based on our partners requirements.

David Henshaw

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.

Greg Griffiths

thats great news :)

Pierre N

Awesome !

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

Thanks,

Pierre

David Henshaw

Hi Harry - if you're monitoring this thread, I see OBuild is now out. I tried running, to no avail, reported that my SRC wasn't a valid module (though it compiles under CSIDE).

What is the expected content / structure of the directory the -src parameter is pointed at ? What is the minimum content of the input?

Does OBuild automate any tasks a developer would traditionally need to do - e.g. producing the module's INI file etc?

I'm also struggling to find any documentation on OBuild - is any available and if so, can you share a direct link? (PS - the link to the SDK documentation online contained within CSIDE seems to be broken, still points to Community Content Server SDK - Online Documentation (opentext.com))

Rgds,

David

David Henshaw

@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

https://forums.opentext.com/forums/developer/discussion/comment/965600#Comment_965600

Hi David,

if it builds with CSIDE, try specifying the "srcmodules" folder of the OScript project in CSIDE with the -src parameter. The source folder for OBuild needs to contain one or more folders with 'modules' which in turn include folders for the OSpaces and the .ini file(s).

Direct link to OBuild documentation is: https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=80169286&objAction=browse&viewType=1. (It is hiding in the CSIDE Quick Start section.)

Regards,

Stephan

David Henshaw

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

Hany Samuel

https://forums.opentext.com/forums/developer/discussion/comment/965600#Comment_965600

I guess Harry is me ? :) I see @Stephan_Baumann just replied your questions about the source folder and documentation. I noticed you mentioned post/replies about regenerating module ini, I will look further into this request and see how we can provide this functionality in OBuild or/and CSIDE.

Hany Samuel

https://forums.opentext.com/forums/developer/discussion/comment/965457#Comment_965457

Thanks @Pierre N , I hope to get your feedback after using the tool. Regarding open source, I am not aware of any plans for this.

David Henshaw

https://forums.opentext.com/forums/developer/discussion/comment/965607#Comment_965607

@Stephan Baumann @Hany Samuel @Juliano_Ghisi

Any chance I could connect via email or a teams call with someone within OT to discuss above observations and "wishlist" re OBuild ?

bartemsa

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.