I’m trying to implement CI CD pipeline using Azure repo and Web methods ABE.

By executing, Build and deploy ABE scripts we are able to deploy packages from repo to target IS.

But in the Target IS > Packages > Management > testPackageName > Package information tab, the Build property is automatically getting updated with the value available in master_build > build_number.

Is this behavior expected and how can we stop this from happening ?

Yes, it does seem to be expected behavior. I just checked the output of my sample build for a CI/CD pipeline I’m actively working on, and inside the package’s ZIP file, there’s a manifest.rel file which contains that build element and whose value is a combination of the properties build.version and build.number.

When you say you want to stop this from happening, out of curiosity, why? And what would you like to happen instead? Would you like a different build number to be used? Or do you not want that build element updated at all?

In any case, here are a few options you can try, listed from easiest to hardest:

1. Pass a different build.number in when executing the build

When calling the build.[sh|bat] script, you could set the build.number property to whatever you’d like ahead of time. Since the property is already set, the Ant target createBuildNumber (inside build-number.xml) won’t really do anything, e.g.:

build.sh -Dbuild.number=$CUSTOM_BUILD_NUMBER

I just played with passing in an empty string as the build.number and it actually resulted in the build element of the manifest.rel file being empty. This may have some problematic repercussions though. For example, if you set enable.archive to true, a blank build.number could cause issues given that it’s part of the archive directory path.

2. Overwrite the build.number properties file with a different file that sets build_number to an integer of your choice

3. Overwrite build-number.xml file with your own Ant script to generate the build number however you’d like. Per the documentation:

build-number.xml. The build script uses this file to automatically version the assets included in the build incrementally. You can customize the file to generate the build number as needed (example, to match the VCS revision number).

4. Update the package ZIP file after the build

Let ABE complete the build, then unzip the resulting packages, edit manifest.rel to remove the build tag using sed or something similar, and then ZIP the packages back up.

Hope this helps,
Percio

Thank you for the detailed explanation!

We were not sure if ABE does the manifest.rel update and so raised the above query. As this seems to be expected behavior for WM Packages, we have decided to keep the property as such for now.

Sounds good. For what it’s worth, I’m also working on a CI/CD pipeline in Gitlab and I’m planning on passing the Gitlab variable $CI_BUILD_ID as the build.number when I call the Ant build script. I’m doing this for a couple of reasons: (1) I’m running ABE inside a Docker container so my build.number file is always the same and (2) I want something more meaningful captured in my package that gives me a direct link to a version in my repository.

Just something to consider.

Percio

I would like to have an opinion on the below query which is also related to WM CI CD process.

Just want to know if you are building the whole config directory every time we create a build or pick selective config files corresponding to each build. Which is the best practice and why ?