here's my dsl as of now
//build.properties.each { out.println "$it.key -> $it.value" }
def workspace = params["CUSTOM_WORKSPACE"]
if (workspace == null || workspace == "" ) {
workspace = "workspace/" + build.properties["environment"]["JOB_NAME"]
}
out.println "Workspace: " + workspace
def b= build("Django (DebugCI)",
CUSTOM_WORKSPACE: workspace,
TARGETS: "Clean;Publish;Build",
RELEASE_MODE: params["RELEASE_MODE"],
ENVIRONMENT: params["ENVIRONMENT"])
def node=b.environment.get("NODE_NAME")
if (node == "") {
node = "master"
}
build("../Templates/Publish Packages",
GIT_COMMIT:b.environment.get("GIT_COMMIT"),
BUILD_NUMBER: b.build.number,
TAGREF: b.environment.get("TAGREF"),
CUSTOM_WORKSPACE: workspace,
NODE: node)
build("../Templates/Build cspkg and Deploy",
GIT_COMMIT:b.environment.get("GIT_COMMIT"),
BUILD_NUMBER: b.build.number,
TAGREF: b.environment.get("TAGREF"),
CUSTOM_WORKSPACE: workspace,
NODE: node,
CLOUDPROJ: params["CLOUDPROJ"],
ENVIRONMENT: params["ENVIRONMENT"],
SUBSCRIPTION_ID: params["SUBSCRIPTION_ID"],
CERT_THUMBPRINT: params["CERT_THUMBPRINT"],
SERVICE_NAME: params["SERVICE_NAME"],
RELEASE_MODE: params["RELEASE_MODE"],
BUILD_STORAGE_ACCOUNT: params["BUILD_STORAGE_ACCOUNT"],
UPGRADE_MODE: params["UPGRADE_MODE"])
On Tuesday, January 28, 2014 6:46:20 PM UTC+5:30, Raghu R wrote:
>
> 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]>
>>
>>> 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.
