ant task for checking-in/delivering modifications to sources during a (dependency) build
Hi,
As a first step when starting a dependency build, I need the build to modify the sources it wants to build. Let's say by adding some comments to the sources that will get built.
I think I can call a custom ANT-script by configuring it as a "pre-build script" in the build definition to do the modification. However, after it changes the source, these source needs to be checked-in automatically I suppose, as otherwise the change is not taken into account during the next steps of the build.
How can this be achieved?
Regards,
Bernd.
As a first step when starting a dependency build, I need the build to modify the sources it wants to build. Let's say by adding some comments to the sources that will get built.
I think I can call a custom ANT-script by configuring it as a "pre-build script" in the build definition to do the modification. However, after it changes the source, these source needs to be checked-in automatically I suppose, as otherwise the change is not taken into account during the next steps of the build.
How can this be achieved?
Regards,
Bernd.
One answer
You can design a build to have several steps (a language definition with multiple translators). The first one could be to perform the source modifications, and the next one(s) to build. It would be something similar to what a precompiler would do.
Does the workflow mandates to put the modified files back into the stream ? or are the changes only for build purpose ? If you need to put the merged files back into the stream, then a post build step would have to be written to do that. Note that developers would see incoming changes in their repository workspaces after a build, which could be odd.
Does the workflow mandates to put the modified files back into the stream ? or are the changes only for build purpose ? If you need to put the merged files back into the stream, then a post build step would have to be written to do that. Note that developers would see incoming changes in their repository workspaces after a build, which could be odd.
Comments
Hi @cgi04291!
Yes, the changes need to be put into the stream, as in a second step they are the input of a dependency build. The current idea is to achieve this by using zImport.
So the full picture would be:
- trigger build
- execute a merge process (= rexx-script submitting a JCL) on the changed members in a PDS
- the outputs are new members in a PDS
- these need to be checked in into the build workspace and delivered to the stream
- generate a mapping-file
-
run zImport
If you have other ideas, please let me know.
Regards,
Bernd.