Maven release perform tries to do a Get to a workspace sub folder in TFS

Audience

Everyone

If you are using TFS and specifically switching from SVN to TFS then you might run into the issue that your Maven release perform tries to do a Get to a workspace sub folder. This will not work as TFS has a validation exception to trying to map a sub folder inside an existing workspace. That could be disastrous in a real situation.

Could you imagine if, while in the middle of a compile, another build kicked off and overwrite your files? Worse if that other build was executing an only slightly different version of your codebase and it created a successful compile of goodness knows what disaster waiting to happen. (shiver.)

To be honest I am not really a fan of the whole compile and release in one tool. The problem is that if I have just deployed and validated a version of the code I want that version deployed. Not a new one, which is exactly what I get it if I compile again. Compiled output always have meta data associated with them and that changes every time you build. So your output, while likely extremely code to your previous compile if the code has changes will always be different. No sensible QA manager would ever sign of on that. A more secure and consistent deployment can be gained by [creating a binary release pipeline] that starts at DEV.

Anyway, this issue was about the maven release perform stage where my build that I am trying to configure to use TFS tries to do a GET of the label it just created (what value there is in this I do not know) to a sub folder of the current workspace. This does not error, but does result in a missing folder and thus a missing .pom file.

[INFO] Scheme - https
[INFO] files: /appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace
[INFO] Command line - /bin/sh -c cd /appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace && tf checkin -login:hinshelwoodmjh,****** -noprompt '-comment:[maven-release-plugin] prepare for next development iteration' /appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace/pom.xml /appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace/TestProjectLibrary/pom.xml /appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace/TestProjectWeb/pom.xml /appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace/TestProjectEar/pom.xml /appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace/TestProjectDistribution/pom.xml
[INFO] err - 
[INFO] Release preparation complete.
[INFO] 
[INFO] --- maven-release-plugin:2.5:perform (default-cli) @ TestProject ---
[INFO] Checking out the project to perform the release ...
[INFO] scmUrl - https://tfs.comapny.com/tfs/DefaultCollection::$/MainProject/VisualStudioALM/JavaTestProject
[INFO] Scheme - https
[INFO] Command line - /bin/sh -c cd /appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace/target/checkout && tf get -login:hinshelwoodmjh,********** -recursive -force -version:LTestProject-1.4.10 /appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace/target/checkout
[INFO] err - 
[INFO] Executing goals 'javadoc:jar deploy'...
[INFO] [INFO] Scanning for projects...
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 0.100s
[INFO] [INFO] Finished at: Fri May 23 14:42:40 CEST 2014
[INFO] [INFO] Final Memory: 5M/10M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] The goal you specified requires a project to execute but there is no POM in this directory (/appl/data/ci-test/jenkins/jobs/TFS-TestProject/workspace/target/checkout). Please verify you invoked Maven from the correct directory. -> [Help 1]
[INFO] [ERROR] 
[INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
[INFO] [ERROR] 
[INFO] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[INFO] [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MissingProjectException
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] Test Project ...................................... FAILURE [42.119s]
[INFO] Test Project - Common Library ..................... SKIPPED
[INFO] Test project - Web Application .................... SKIPPED
[INFO] Test Project - Enterprise Application for web application  SKIPPED
[INFO] Test project - Distribution project ............... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 43.130s
[INFO] Finished at: Fri May 23 14:42:40 CEST 2014
[INFO] Final Memory: 14M/31M
[INFO] ------------------------------------------------------------------------

This understandably results in a failed build/release. Not only did this one take a while to understand I had to consult with an awesome Java expert in the form of Corstijan Kortsmit who identified the solution in about three seconds. It was one of those “Oh… that… you just…” sort of answers.

clip_image001

If you head over to the configuration of your build and look for a section entitled “Build Environment”. Here there are two important sections. We have a couple of boxs to put additional command line parameters for the maven release plugin. We need to add at least a “-DworkingDirectory” parameter with a specific folder for where to do the get.

-Dresume=false release:prepare release:perform -DworkingDirectory=/appl/data/temprelease -Dgoals=clean install

The additional issues to think about are around multiple users as well as multiple builds working simultaneously and multiple users.

Multiple builds is solved by adding parameters for something unique to the instance. In Team Build each ‘Agent’ can only run one build at a time but you can run multiple agents on a single server. Each agent gets a unique ID and by default TFS created a distinct workspace for each instance that can be shared across instances of the same build. This makes the second build potentially faster on any given agent as you don’t need to always clean workspaces as you can sync them. Here I could not see an agent ID so we went with the Build Instance ID. The down side to this is that you have to do a full get for every build and it might be slower.

Multiple users is an easier issue to solve. We added pre-build commands to create a workspace in the folder above and we made it ‘public’ meaning that any user can use it. By default a workspace is created as ‘private’ and another user can’t use that folder. With a ‘public’ workspace we can have the first user create it and then reuse it time again for other users.

This got the build working. Our only outstanding issue now is that build from SVN have a Tag created. In TFS this is done as a label, however labels are mutable. They can be changed after the fact with no audit record. We will likely solve this by creating a read-only branch instead of a label.

Let me know how you get on with your migrations to TFS.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Read more

Martin Hinshelwood
The Boards in Azure DevOps are a powerful tool that your teams can leverage to enable transparent visualization of the current state of value delivery.  However, the inclusion of Blocked columns can stealthily erode the very foundations of efficiency these boards are meant to uphold. By obfuscating the state of …
Martin Hinshelwood
This week, I participated in a Scrum.org Webinar hosted by Sabrina Love (Scrum.org Product Owner) as well as my colleagues, Joanna Płaskonka, Ph.D. and Alex Ballarin 🇺🇦 to discuss the state of learning and how immersive learning is the future of training. You can watch the video below to hear …
Martin Hinshelwood
Business Leaders face a key challenge when scaling their organisations effectively while maintaining the distinctiveness that made us successful in the first place. Many frameworks and methodologies, such as Scaled Agile Framework (SAFe) or the Spotify Model, promise a structured approach to scaling, but do they genuinely fit our unique …
Martin Hinshelwood
As we inch further into the dynamic landscape of the 21st century, our long-established Alpha organisations stand on shaky ground. The organisations whose DNA is infused with strict command and control, woven into the fabric of every process, are feeling the tremors of a rapidly evolving, technologically charged market. Not …