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]> > 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]. > 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.
