I am having difficulty running multiple instances of the same pipeline simultaneously. Once one instance is running, it doesn't seem to allow another one to be triggered until the current instance has completed. I have the setting "Automatic pipeline locking" unselected, so I'd expect that it would allow simultaneous execution.

Are there other settings that impact the ability to run simultaneously?

I'm using Go to build projects that are hosted on Git repositories. These git repositories have submodules in.

It seems that about every minute when polling, the Go server will wipe the submodules and re-clone them, which is causing an excessive load.

Why would it be doing this? It can surely keep syncing the existing submodule clone.

For that matter, why does it even need to checkout the submodules? The changes needed to be detected are in the parent repository, as submodules checkout are essentially commit hashes stored in commits to the parent repository.

The Go server log frequently has the following log line in (about every 2 minutes):

WARN [materialUpdateThread] MaterialUpdateService:60 [Material Update] Skipping update of material GitMaterial ... which has been in-progress since [about 1 minute before]

I'm sure that a git hook initiated build is more ideal, but I'd prefer to poll if it is as efficient as it should be.

The Go server version is: 2.4.0

The git version is 1.7.4.1

Kind Regards

Andy

 Hello, I am trying to evaluate Go for my companys build tool. I installed Go V2.3.1 on Ubuntu 11.04. Everything installed without errors and the server says it is starting up ok and to visit http://servername:8153/go, but when I go to the page there is nothing running. I have looked in the log and found no errors. And using  sudo /etc/init.d/go-server status it returns running. After about 5 min the server shows stopped. I poked around a bit but can't seem to find the answer. Can anyone provide me with some troubleshooting steps? I have attached a log file from start, hit the address with a browser, wait, then the server stops itself.

Anyone have any thoughts?

Hi, I'm new to Continuous Integration and Go Server...

I've set up a test pipeline that basically builds a console app then runs FxCop and NUnit on the created DLLs and EXE. The Build is done in stage 1, the Tests are done in stage 2.

When trying to fetch the artifacts from stage 1 to stage 2, I received a "Access is denied" error on the second artifacts (buildfiles). I don't know why exactly, but it seems to be related to the .SVN folder. (see logs)

Do you have any ideas what I could do about this? I was thinking about ignoring the .svn/ folder from the artifact, but I don't know how to do that...

Here is part of the config file:

      <stage name="Build">
        <jobs>
          <job name="build">
            <tasks>
              <nant buildfile="buildfiles\default.build" target="build">
                <runif status="passed" />
              </nant>
            </tasks>
            <artifacts>
              <artifact src="buildfiles/*" dest="buildfiles" />
              <artifact src="ConsoleApplication1/bin/Debug/*" dest="bin" />
              <artifact src="Tests.Model/bin/Debug/*" dest="bin-tests" />
            </artifacts>
          </job>
        </jobs>
      </stage>
      <stage name="Test" fetchMaterials="false">
        <jobs>
          <job name="FxCop">
            <tasks>
              <fetchartifact pipeline="" stage="Build" job="build" srcdir="bin">
                <runif status="passed" />
              </fetchartifact>
              <fetchartifact pipeline="" stage="Build" job="build" srcdir="buildfiles">
                <runif status="passed" />
              </fetchartifact>
              <nant buildfile="buildfiles\default.build" target="fxcop">
                <runif status="passed" />
              </nant>
            </tasks>
            <tabs>
              <tab name="FxCop" path="reports/fxcop-results.html" />
            </tabs>
            <artifacts>
              <artifact src="reports/*" dest="reports" />
            </artifacts>
          </job>
          ...

Thanks a lot !

dstj.