Comments
The agents can be made to run certain jobs in certain order only via configuring the jobs in the right way.
So, in this case you can put the jobs in different stages, so that the process becomes sequential automatically.
Example:
Pipeline-1
Stage-1
Job-1 (First agent runs this job, in which it installs binary using bat script)
Stage-2
Job-2 (Second agent runs this job. It will not get triggered until Stage-1 has passed, hence will wait for it.)
Hi Lee,
No, it is not advisable to start an agent from another agent as part of a job run.
If starting the agent via the command line is not an option, then there are a couple other options which can be tried.
1. Can the prefast command be run using "cmd /c" from within your build file.
2. You could use a custom command instead of a nant task. Example:
<exec command="cmd /c" args="nant -buildfile:#{BUILDFILE} preBuild captureEnvSettings versionAll build.fsVidCommon">
<runif status="passed" />
</exec>Hi Srinivasa
Do you mean that your go agent is trying to install some binary using a batch script, and you need to track that operation?
I'm sorry , but could you elaborate on your question? It will help us answer it better.
Regards
Shilpa
Yes, thats right.
@Manoj: Thanks, I missed that.
Hi Hong,
In case of windows, a go agent checks out the repository under the path <go_agent_installation_dir>\pipelines\<pipeline_name>\<dest_folder_if_given>
And this is the working directory for all tasks. So just finding the current working directory (pwd or cwd) should give you the path required.
To investigate this issue further we'll need to have a look at the agent logs and console logs.
Could you a log a support ticket by emailing to support@thoughtworks.com. Please attach the go-agent.log and console.log of the job along with this email?
Thanks
In addition to what Manoj said about evironment variables.
Parameters cannot be accessed in a script outside of go. They are purely provided to customised the GO configuration itself. In your example, #{paramStub} can be used to define any other config element within the pipeline config.
You should be able to get the required exe from this link http://mercurial.selenic.com/release/windows/ .
HI Mike,
There are a couple possibilities for this to happen. One of them is that the workspace was first mapped to the flyweight folder "D:\Cruise Server\pipelines\flyweight\e815b9ba-098a-4a57-a62d-23523790844c" . But maybe now Go is not able to find that folder (maybe it got deleted) and hence it created a new folder.
As a fix, you should delete this workspace and all its mappings manually. It may be a good idea to stop the Go server when you do this, so that the Go server does not recreate the workspace before you are done with the cleanup.
Regards
Shilpa
Hi,
Have you tried invoking the build commands using shell-script? The shell-script can load shell-rc file, hence rvm configuration.
Regards
Shilpa
Yes, in case of agent the only way to do this is to create a sym link to the required folder.
I'm glad that worked for you.
FYI, even in case of the go server, of the "pipelines" folder needs to be in another folder, this would be the way to do it.
Could try using an older version 1.8.1 or 1.9.1 of mercurial and see if you still get the error?
What is the version of hg client which you have installed on the server?
By any chance do you have two different hg clients in different paths? If so, what are the versions of those?
I have a couple of questions for you:
1. Could you confirm if the security is turned on, in your go server? If so, do you have adequate permission for accessing the pipeline?
2. Could you post the exact api as you are trying it?
Hi Yandong,
Please upload the log file go-server.log along with the cruise-config.xml. This will help us troubleshoot the issue better.
Thanks and Regards
Shilpa