Hi Nicolas, Right - build orchestration is my intention too (mostly). However, workspace isolation is important so that jobs in the build flow have a predictable workspace state. Specific scenarios are in my previous wall of text - but I'll try to summarize the core issue here:
Typical Execution Flow 1. Build debug CI ----> this checks out sources (about 25 mb, then installs packages so the workspace is about 400Mb or so, then builds and runs unit tests) 2. Create packages ---> this needs the overall workspace in its entirety 3. Deploy -- needs to again operate on the workspace. Now I don't want to checkout sources at each step - kind of defeats the purpose. So one option is to mark the build number from the first step and publish artifacts that the next step can use - but this doesn't work in my case since I need the entire workspace. Next option is to use shared workspace and/or clone workspace Clone workspace etc work by archiving the entire workspace and then passing it on. And it isn't very flexible since it needs job dependency (upstream/downstream). Setting job dependency is not an option for me since I want to have the Build Debug CI build work on its own as well.. Using the Build Debug CI build's native workspace is not an option since a build flow might be in progress that's using the workspace and at that time SCM Poll might trigger a Build Debug CI build. Hence the approach of using the Build flow's workspace as the common area where each job in the flow operates on. It works pretty well and lets me achieve what I intended... what is frustrating is that I cannot surface the results in one place. So for a user who kicks off a deployment needs to jump around to each build job to see details.. Apologies for the wall of text again! On Tuesday, January 28, 2014 6:21:15 PM UTC+5:30, Nicolas De loof wrote: > > build flow is an orchestration DSL, not a replacement for existing plugins > (clone workspace, copy artifact, etc) so removal for workspace support. > I don't understand what you try to aggregate using a shared workspace. Can > you please add some details, with a typical execution chain ? > > > 2014-01-28 Raghu R <[email protected] <javascript:>> > >> This is an old topic that has been discussed before in another context >> >> I'm trying to migrate from Teamcity to Jenkins. >> >> I've started using the build flow plugin to factor out and orchestrate >> build steps. A little context: >> >> I have multiple repos - Repo1, Repo2, Repo3... >> Each Repo contains a single .NET solution and may produce one or more >> Nuget packages that are uploaded to a repository >> Some of the Repo can also be packaged into Azure packages and deployed on >> the cloud. >> >> I am also using ez-templates (https://github.com/JoelJ/ez-templates) >> based on a SO recommendation to templatize complex builds. >> >> Job Templates: >> Debug CI - has an SCM (Git), downloads the code and builds and runs unit >> tests. >> >> Common Jobs: >> Package : Given a workspace, packages all nugets in the workspace and >> uploads to nuget server >> Deploy: Given a workspace, use a powershell script to deploy to azure >> cloud service >> >> So build flow seemed a good idea and I have the following setup. >> Repo specific Jobs >> 1. Debug build - Templatized from DebugCI, runs on each commit - reports >> unit test results >> 2. Build and Package - Build Flow - invokes Debug Build followed by >> Package. >> 3. Build, Package and Deploy - Build Flow - invokes Debug Build, then >> Package and then Deploy >> >> One issue was the workspace to use. I did not want to end up using the >> first job's (which clones/pulls from Git) workspace since while the second >> step in the flow is going on, someone could trigger another build etc. >> Also, I did not want to check out multiple times etc since that's just >> overhead. After considering shared workspace and Clone workspace, the >> approach I've settled down on is to parameterize the workspace. It defaults >> to the Build flow job's workspace - so in the above, when say, Build and >> Package invokes Debug Build with the workspace "/workspace/Build and >> package". That works great - since all the work is happening in the flow's >> workspace and there's no blocking of the invoked builds (since they all run >> in the flow's workspace) >> >> What I'd like to do to make this more ideal: >> >> 1. Console output - aggregate from the invoked builds >> 2. Other artifacts - like tests, packages that were uploaded to package >> repo as part of the Package job, or the deployment package generated in the >> Deploy job to be aggregated into the Build flow's workspace. >> >> Unfortunately, looks like the workspace has been removed from Build flow >> - so is there a way to surface the build artifacts and build logs of a >> build flow? >> >> PS: I really really would love if the workspace was disabled by default >> but available if needed. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
