This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Remote repository coming in late

Apr 15th, 2010, 05:00 PM

dm Server 2.0.1.RELEASE:

Not every time, but more than not, my remote repository becomes available after dm Server attempts to install my plan files. This causes the plan to fail because all the required bundles are on the remote repository. Log looks something like this:

Comment

Hmmm. There would be a race like you are seeing if you are copying artifacts into a remote watched repository RW and attempting to deploy a plan that references any of those artifacts on a dm Server instance with RW in its repository chain. But copying unrelated artifacts into RW shouldn't have a disruptive effect on a server with RW in its chain.

Comment

Thank you. That is quite likely what's going on. The remote repository is getting updated with the latest continuous integration builds all the time, so it's likely that bundles I would be using would be being updated.

The goal is to have the latest builds of bundles on a remote repository so that a developer, that is only working on a single bundle, doesn't need to check out the entire application, just the single bundle and the plan file.

Is it possible to have bundles in the stage repository take precedence over bundles in the other repositories? If I had a bundle of version 1.0.0 checked out, and the latest build in my remote repository was 1.0.0.CI00012, the CI build always gets used.

Comment

To make your version override the version in the remote repository, you need to add your version to another repository in the chain. Presumably it would be most convenient to copy your version into the watched repository directory, e.g. repository/usr. Also, give your version a higher version than that in the remote repository, e.g. 1.0.0.Dnnnnn.