Comments
Please use "GO 2.3 EA" as the user. Sorry for the mixup, and thanks for pointing it out.
Try using port 465 (instead of 587).
The cache files are scoped by unique identifiers. If you re-run a pipeline that fetches an artifact, Go will serve up the cached copy if it exists. If you re-run a pipeline instance that generates an artifact, those artifacts will be re-zipped if an agent requests for that particular pipelines instance's artifacts.
Go takes care of aspects caching and scoping. Whenever you request an artifact in your job, you don't have to worry about whether or not you're getting the correct artifact -- rest assured that Go will send you the correct version of the artifact.
Hi Brett,
Whenever an agent requests an artifact from the Go server, the server zips up the artifact and sends it to the agent. The artifacts cache is where the zipped files are persisted for quicker response times.
It should be fine to clear out the cache dir from time to time. The only thing to watch out for is that you don't want to delete an artifact that still has not been fully downloaded by an agent. You might want to do a timestamp check on each file before deleting them (don't delete any file that was created less than an hour ago).
Hi Dan,
You can pass credentials to an Hg repo using the following syntax:
https://user:pass@my.repo.com
Hi frank,
Go does not support timer triggers at the stage level, so your "complicated" solution in fact would be the way to go.
In terms of figuring out the last stage that ran, you can use the stages feed that Go exposes:
/go/api/pipelines/[pipeline_name]/stages.xml
From this feed, you can figure out the last run stage for that pipeline and based on that, you can choose to trigger the stage or not.
Applied a minor style fix: https://gist.github.com/1050589
Can you provide the full version string, including the build number please? Should look something like "2.2.0 (12345-1b3185eb05617c)".
Hi Stephen,
What version of Go are you using (found on the footer)?
This sounds similar to an issue we saw with another customer. If you see this issue manifest again, do let us know. It appears to happen under some very specific scenarios.
To answer your last question, there is a max length (255 chars), but that was definitely not an issue with your stage name.
Hi Thomas,
You can customize the agent name via the Source XML. Refer to this post for more details.
Lee,
In order to retrieve the generated artifacts, you'd likely have to go to the job details page anyway, right? The job details page does list the agent name on it. Does this work for you?
I'd also like to mention that in Go 2.3, we're coming out with an new screen that gives you details about each agent. If the purpose of your script is to get some data around the agent, what kind of data are you extracting? I ask because it may be good feedback for features that could possibly go into the new agents page.
Looks like glob patterns are not supported for test artifacts. We'll log this as a bug.
Lee,
Could you elaborate on why you need to identify individual agents. I understand that you have multiple agents on the same machine, but each agent is sandboxed, so they should not conflict with each other.
Ideally, your scripts should be completely agnostic to what agent they are running on. Only then would you be able to make full utilization of the flexibility of the agent grid. If your scripts are agent aware, that would introduce a lot of unnecessary complexities within your scripts.
Mark,
Considering you can already perform an XSLT transform, wouldn't it be great to fully automate the process of creating branches? Go exposes an API through which you can modify the config XML.
To modify the XML programmatically:
GET http://goserver:8153/go/admin/configuration/file.xml
This will give you the full config XML and the response will contain an HTTP header called X-CRUISE-CONFIG-MD5 which contains an md5 digest of the config file. You'll need this value when saving the modified config.
You can now run your custom script to parse and update this config.
To update the config POST to /go/tab/admin with params:
xmlFile=<updated config xml>
md5=<md5 from the header>I understand that this does not give you back the edit XML partial functionality, but that was intentionally removed so that only system admins are able to modify XML directly. We are definitely taking feedback into the use cases that our customers have for the XML partials and will certainly work on addressing all of those use cases via the new UI.
Your scenario is a great example of how you might want to "clone" a pipeline and make some changes. I think the cloning feature is certainly a valid one which we will prioritize.
You could try configuring the artifact to appear in a custom tab.