I am working on a product which needs to be supported by different version of web-sphere(7.X,8.X and 9.X). I have to perform different build tasks(like copying different properties) based on WebSphere version. How can I determine the WebSphere version dynamically while running any build script.
Assuming you have the ability to run a script from your build environment, you can run the versionInfo.sh|bat file in the WAS_HOME/bin directory. That'll provide way more information than you need, but you should be able to parse the output for the build level (in the output, it's labeled as "Version").
Related
I have completed build automation of Eclipse RCP application using maven/tycho.
Now I want to make it more seamless. So I am checking if we can auto-increment application version with every build.
for e.g. As you can see in attached picture, snapshot of .product file. enter image description here
Version is 1.2.0. So with every build, it should increase the version number 1.2.1, 1.2.2, 1.2.3, and so on, without changing the version manually in product file. Once I execute the parent pom(trigger the build), it should also increment app version and complete
the build process, all in one command that is mvn install.
can we achieve this using maven/POM.xml or please suggest any other solution??
You can use the goal parse-version of the org.codehaus.mojo:build-helper-maven-plugin (documented here: https://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html). This will store the parts of the current version in some properties (by default, parsedVersion.majorVersion, parsedVersion.minorVersion and parsedVersion.incrementalVersion). You can use such information to compute the next version number as you see fit.
Then, since you are using Tycho, you can pass these properties appropriately to the goal set-version of the org.eclipse.tycho:tycho-versions-plugin (https://tycho.eclipseprojects.io/doc/latest/tycho-release/tycho-versions-plugin/plugin-info.html).
Here you can see a simplified example using these two goals to remove the -SNAPSHOT and .qualifier: https://www.lorenzobettini.it/2020/02/remove-snapshot-and-qualifier-in-maven-tycho-builds/.
As I said, in your case, you'll have to do a few more operations to compute the next version number.
When a private agent build starts in VSTS, it gets assigned a directory, e.g. C:\vstsagent_work\1\s
Is there a way to set this to a different path? On other CI servers, like Jenkins, I can define a custom workspace for a job. I'm dealing with a huge monorepo and have dozens of build definitions around the same repository. It makes sense (to me anyway) to share a single directory on the build agent computer.
The benefit to me is that my builds can use pre-built components from upstream repositories, if they have already been built.
Thanks for any help
VSTS build always creates a working directory per build definition. This leaves you two options:
Create a single build definition and use conditionals on steps to skip certain steps in order to only run what is needed. This allows you to use the standard steps and may require a powershell script to figure out which steps to run and which ones to skip. Set variables from powershell using the special logging commands.
Disable the get sources step and add a step that manually fetches sources. You'll need to clean the working directory, checkout the right commit, basically replicating the actions in the get sources step manually. It may require some fidgeting to get all the behavior correctly for normal build, pull request builds etc. That way you can take full control over the location where sources are checked out.
I'd also recommend you investigate the 2017 project formats that use the new <packageReference> in the project files to fetch packages. The new system supports configuring a version range which can always fetch the latest available version of packages. It's a better long-term solution.
No, it isn’t available in VSTS build system.
You can change working directory of agent (C:\vstsagent_work) (Re-configure it and specify another working folder), but it won’t uses the same source folder for different build definitions, the folder would be 1, 2, 3 ….
I did my build numbers as 1, and then 2.
Does this matter - is it just a mater of preference as to how you do them?
The Build Number (or CFBundleVersion) is not shown in the App Store so for the user it does not really matter.
The purpose of the Build Number is that developers can distinguish different builds using the same Version (CFBundleShortVersionString).
Consider you are working towards a version 2.1.0. Before you publish this version on the App Store, you probably want to distribute Beta builds to testers. If they report any issues and you fix them, you will need to create and upload a new build but probably still use the version 2.1.0. In that case you would use the Build Number to distinguish the two version.
You can use whatever you like as a build version. Apple provides a tool to increase the Build Number in Xcode projects named agvtool.
Another way (and what I personally do) is to use the git commit count as the Build Number. This can be automated via a Build Phase. That way, every change that you make (and commit) automatically increases your Build Number.
Is there a simple way to set the TFS Build Number to be an Assembly Version during build?
I've seen many examples of the other way around (i.e. a build number updates the assembly version).
We already use the SharedAssemblyInfo implementation from here, so we would like to leverage this setup during the build process.
Currently using TFS 2012 with Release Management template (ReleaseDefaultTemplate.11.1.xaml).
Without modifying the build process template? No. Even then, the build number is set prior to compilation (or, IIRC, even syncing the code from source control), so you're in for a wild ride trying to get the behavior you want.
I am new to Jenkins CI tool and I want to know if it is possible to specify what build to use when there are several projects, on different SVN locations, dependent on one another. For example, if I have the web project on SVN location1 and the backend project on SVN location2 and the web depends on the backend and one of the developers modifies something in backend, when the web developer does a commit, there will be a build failure. Is there the possibility to specify that the build from the web part should take into consideration build x from backend and not the newest build?
Thanks in advance.
yes that can be done. in Jenkins check for the Build Triggers options in your project web-settings and on the line Build after other projects are built you can specify the name of projects you want to build automatically after there has been changes made to the base project.
And similarly, in the Post-build Actions, look for Build other projects, where you can specify that if the base project builds successfully, it will automatically trigger a build on children projects.
Hope this helps.
Your example of building a project against a specific version of another project is a little non-standard, but not impossible.
In your case, I would use Jenkins' ability to execute arbitrary scripts to help. The script would take care of getting the correct version of the project that the one I want to build depends on.
Building on your example of a Web and Backend project, here's how I would do things without using a parametrized build:
Add a file to the repository of the Web project that stores the version of the Backend project to use
Configure a job to build the Web project when the source for the backend project changes in SVN.
The project should check out the latest version of the Web project
The first Build Step for the project would be a script (Execute Shell or Execute Windows Batch Command) that does the following:
Gets the version of the Backend to use from the file containing the version info
Either pulls the appropriate version of the Backend from the Backend's repository; or pulls the source of the appropriate version of the Backend's source
(If you pulled the source only for the Backend, the next Build Step should be to build the Backend next)
Build the Web piece
Do any unit tests