Passing version number from build servers

[Jbekker]

I'm currently looking into using this tool and integrate it in a Azure DevOps Pipeline, one of our requirements is that the version number is set during the build. I guess I can update the mta.yaml but it would be much easier if the version number can be passed as a parameter to mbt build.

Are there alternative methods available?

[katunin-ng]

@Jbekker this functionality is not available in the tool. The only solution is to modify the mta.yaml file in your pipeline before build. We will evaluate this requirement and decide on when to include it into our roadmap. Meanwhile, would you consider contributing the implementation? You can learn how in this link: https://sap.github.io/cloud-mta-build-tool/process/

Regards Natalia

[olirogers]

I have been looking into this and there are a couple of options to solve it and I wanted the team's guidance on the approach for a potential PR:

1. No code changes Store MTA yaml as mta_base.yaml (or similar) and as part of the CI process, add the version (e.g. from GIT):

e.g.

> VERSION='4.0.1+88d3b36' # (or describe from git tags or similar)
> echo 'version: ' $VERSION >> mta.yaml 
> cat mta_base.yaml >> mta.yaml
> mbt build # Uses generated mta.yaml for the build process

(Note, mta_base.yaml is exactly a valid mta.yaml minus version tag). Potentially this could be added to the documentation?

2. Should this be possible to do with MTA extensions?

For example, consider this extension file:

version: 4.1.10
ID: com.myorg.app.ext
extends: com.myorg.app
_schema-version: 3.3.0

> mbt build -e=verson.mtaext

Note that even though the mta extension is valid, it doesn't seem to change the version number of the generated mtad.yaml or mtar package. Is this a bug in the handling of MTA extensions? No error is reported, it just doesn't do anything useful! It also doesn't behave in the same way as cf deploy does with extensions.

I think this doesn't work due to mbt gen meta and mbt gen mtar not using the extension parameters properly but needs further investigation.

3. Command line flag to change the version

Potentially tricky as version is read from MTA file when running the make file in multiple places. It would need to either be a parameter to at least mbt gen mtar and mbt gen meta and possibly mbt validate? There is a version parameter in the makefile itself, but that seems to always be set to 0.0.1 and not used anywhere.

What are your thoughts on this? Is this useful?

[tal-sapan]

Hi,

Note that even though the mta extension is valid, it doesn't seem to change the version number of the generated mtad.yaml or mtar package. Is this a bug in the handling of MTA extensions? No error is reported, it just doesn't do anything useful! It also doesn't behave in the same way as cf deploy does with extensions.

The extension descriptor doesn't have a version key in its schema, and it cannot be used to override the version in the mta.yaml file. This is not a bug - the version isn't specified as a key that can be overridden (for development or deployment descriptors). You can see for example the Defining MTA Extension Descriptors documentation and the MTA Specification section 4.2.

Does changing the MTA version with an MTA Extension descriptor file work for you in deployment?

[katunin-ng]

HI,

I think is that option #3 - "Command line flag to change the version" is the way to go. The provided parameter should be considered only for generating the result 'mtad.yaml' file in the relevant commands. This enhancement is not our short-term plans yet. But we'll gladly accept this feature as a contribution. Thank you Natalia

[katunin-ng]

Hi @olirogers ,

Tal proposed option #4. An additional command for setting the application version in mta.yaml. Using this command (e.g. mbt set-version), you will be able to set the required version before activating the 'mbt build' command in your pipeline. What do you think?

Regards Natalia

[Jbekker]

One last option, allow overriding the version through an environment variable. What do you think about that? mbt set-version could set the environment variable but then you could also set it directly through CI tools.

[katunin-ng]

@Jbekker , the environment variable is the less preferable option. It requires additional command that needs specific implementation for different OS. It has the same implementation complexities as the options #3 above. And it is less clear than option #3 wrt what version will be used in mtad.yaml in the general case.

Regards Natalia

[P1ll3P4ll3]

When will this bug get fixed/this feature be implemented? We have the same requirement.

To be more specific: We want to use the maven release plugin, so we must pass the version number from our Azure Build Pipeline. Maven creates the corresponding branches and tags with corresponding version numbers in its pom-files and Maven pushes them to the repo.

As far as I understood this can be achieved by using a custom builder and specify the command. We would have to pass the version number of the current release, name of the branch and name of the tag to maven. As well we would have to change the version number in the yaml-file.

Edit: This feature is very important to automatically create versions without using other tools like sed to change the version number in the yaml file and to be able to pass other variables to the build process via MTA.

Is there even any activity on this project because the last message was posted over one year ago. Is this tool already outdated? Should we still use MBT?

[sapcode]

Dear Natalia, is this feature on the roadmap, I think there are many people needing such functionality. Best regards Operator

[katunin-ng]

Hi, I am not involved in this project anymore and cannot answer the questions about the tool's roadmap. @rimasirich probably you can?

Regards Natalia

[AvitalMargalitSAP]

Hi everyone, Thank you for specifying your requirements. My name is Avital and i'm the PO of this feature. We'll add this support during Q3/4 2022. I added it to our roadmap.

Best regards, Avital

[zyhmichelle]

Hello @AvitalMargalitSAP , may I know whether it has been implemented yet?