Feature Requests
Use this forum to post things that you would like to see in future versions of Go
Welcome Guest
Log in if you have an account.
Otherwise, register for an account.
For more details, please visit the How This Site Works page.
Forums
Feature Request Recent Posts
Post posted February 6, 2012 by Scott BaldwinI've been hacking around trying to find who triggered a pipeline from within a Go job. Looking through the feeds API I mananged to find some value, either "changes" or the username of some person who manually triggered the pipeline.
Here is a ruby script that shows how to get either the username (if manually triggered) or the authors of changesets in materials: https://gist.github.com/1731305.
If you don't care about who made the changes you can use this ruby script: https://gist.github.com/1753163.
The second approach is based on feedback from the Go dev team. Still using the API, you use this URL:
url = "#{ENV['GO_SERVER_URL']}pipelines/#{ENV['GO_PIPELINE_NAME']}/#{ENV['GO_PIPELINE_COUNTER']}/#{ENV['GO_STAGE_NAME']}/#{ENV['GO_STAGE_COUNTER']}.xml"
Then, use XPath to lookup //approvedBy/text().
Ultimately, it will be cleaner to have an environment variable on the Go job with the value of the "approveBy" XML element. This has already been logged as a feature request, but I wanted to share the undocumented API and a programmatic way to use it.
Post posted February 3, 2012 by Alex SchwartzI like the feature to filter the shown pipeline groups and pipelines on the main dashboard. As I have to switch quite often my context and focus, I would love to have multiple views.
A view should have a name, and the usual CRUD operations: Create, update, delete, maybe no read operation. The views should be persistet, and belong to a single user only.
Recent Comment (1 of 1)
- February 5, 2012 by Santosh: Hi Alex, We have custom views in our backlog. Can you elaborate on...
- Post last edited February 3, 2012 by Alex Schwartz
With subversion hosted code we like to add the revision number to the pipeline label. After migration our code to git we would like to have the git revision number reflected in the pipeline label, but the full git hashsum is far too long for that.
Expressed using GIVEN-WHEN-THEN I suggest the following acceptance criteria:
Post posted February 1, 2012 by Steve ElkindAs administrator of a pipeline group, in a Go server supporting multiple business units and projects, and that is also used for secure production deployments, I need to be able to maintain the pipeline templates that my pipeline group uses. However, this must be possible to accomplish this without being given full Admin privileges to the Go server, as the security of other pipelines, users, and the Go server itself would be compromised.
Preferably just my own templates scoped to my own pipeline group, or being given admin privileges to specific templates, but scoping my admin access to all pipeline templates would for now be an acceptable alternative.
- Post posted January 23, 2012 by Steve Elkind
As a pipeline group administrator, I can add users and assign permissions to pipelines in my group, but I can not add users to groups associated with my pipelines. As the number of users and pipelines in my group grows, this becomes cumbersome.
Being a delegated role administrator to mange role membership for specific groups would make managing the users of my pipeline group easier.
Recent Comment (1 of 1)
- February 1, 2012 by Steve Elkind: Actually, now that I think about it, an alterative solution to the...
Post posted November 10, 2010 by Ian Bridsoncurrently if you approve a stage at the individual pipeline view you are asked in a pop-up if you wish to approve the stage. This is good but i would like to see this go further and prompt with a dialogue to change any stage level environment variables, if any are defined. This would allow the user to pass of fail a stage for instance, by changing a variable and then running the stage. If i accidentally passed the stage when i shouldn't have i would also like the rerun function to prompt for environment variables again as well, so that it can be marked failed,
As there maybe dependent pipelines for this stage then idelaly failing this stage would make previous runs of the same 'build' unavailable to downstream pipelines.
Recent Comment (1 of 1)
- January 25, 2012 by Russell Teabeault: I second this request.
Recent Comments
- February 5, 2012 - Hi Alex, We have custom views in our backlog. Can you elaborate on...
- February 1, 2012 - Actually, now that I think about it, an alterative solution to the...
- January 25, 2012 - I second this request.
