It would really be nice to set the ${COUNT} used for a pipeline to start at a specific value.  Additionally, it would be nice to allow the string length of this value to be set (i.e 5 digits, 6 digits, ...) such that leading zeros would be added.

As our branch scheme involves creating a branch from our main trunk whenever we are preparing to release, the new release branch would assume the value of the main trunk and the main trunk would be incremented to always be greater than the latest branch created.

ex: main labeltemplate=12.0.${COUNT}

create a new release branch labeltemplate=12.0.01${COUNT} such that COUNT is same as the last one in main

increment main labeltemplate to labeltemplate=12.0.02${COUNT}.

I would like to request support for AccuRev SCM from Cruise.

Is there a plug-in or anything similar that already provides this?

Here's the scenario: 

"As a developer I frequently need to download whole directory artifacts from Go so that I can pass the artefact to the Ops team for release to a production system (not every pipeline is automated all the way to live yet) or to use parts of the artifact locally on my PC."

Currently downloading whole directory artifacts through Go's Web UI is very hard to do. 

Because of this all our pipeline build scripts compress all directory artifacts as 7-zip archives and then Go is configured to store the 7-zip archives as file artifacts instead of as directory artifacts.  In later pipeline stages/jobs the builds scripts then have to decompress the 7-zip archive artifacts.  We also have to bundle the 7-zip command line tool (i.e 7za.exe) with every codebase. 

Storing all directory artifacts as 7-zip archvies also (I think) reduces the disk space used by Go for storing arifacts as 7-zip archives are a very efficient for archvie size (7-zip does file deduplication).  Does Go do any artifact file deduplication based on MD5 hash etc.  I've noticed over the last few months that Gradle's cache and SVN's .svn\pristine in SVN 1.7 both seem to be doing this or something similar.  

It would be great if Go had an option for storing directory dependencies as 7-zip archvies, if it would decompress those archives when fetching them in a job and if it allowed you to download the 7-zip archvies through the Artifacts tab of any Job (in the Pipelines section of Go not the Admin section). 

7-zip would be essential (over zip files and tarballs) as it is so much more efficient at compressing archives that contain the same file more than once – we get that lots with .NET codebases were release packages tend to contain many copies of the same DLL – e.g. a Spring.NET DLL being used in lots of the multiple applications in the same release package. 

Thanks

Simon  

It would be very useful to be able to add an SVN material to a downstream pipeline and have it checkout the same SVN revision as its upstream pipeline.  

As an example

CI Pipeline => Test Environment Deployment Pipeline

The CI Pipeline has an SVN material.  Go today allows the Test Environment Deployment Pipeline to share the same SVN material as the CI Pipeline, however there is no way to force the Test Environment Deployment Pipeline to checkout the same SVN revision as the CI Pipeline build that triggered it.  

The lack of this features means that today I have to put everything needed for a deployment into a build artifact and pass that from the CI Pipeline to the Test Environment Deployment Pipeline.  This is proving far to complex and cumbersome.  I'd rather just put the build output (e.g. compiled code) in the artifact passed from pipeline to pipeline and then get everything else from SVN. 

Please ask if you need any more info or clarification

As a Go pipeline administrator, I want to migrate a set of pipelines (either a pipeline group or a subset of a group) from one Go server to another existing Go server.  The second server is already in operation with multple other pipelines that can not be disturbed.  What is really needed is some way to export/import the set without the risk of messing up my second Go server's configuration and operation by manually editing the overall config XML.

Background:  we have a QA Go server which serves as both QA for Go itself and as a sandbox for projects new to Go that are just learning the ropes.  When they are ready, we migrate their initial pipelines to our production Go server for the rest of their existence.  The reason we do this is our production Go instance is shared by multiple BUs/projects and is used for production deployments.  Up to now we've just been cutting-and-pasting XML fragments in the config source view, something I'm not crazy about due to the potential risks....