Hi all,

just downloaded my copy of Cruise server to get started with eval. I notice that it isnt possible to set up a pipeline with no SCM integration? Is this correct?

I have literally installed it etc, with a view to creating a project/pipeline to test out a script I have been working on. However I dont need any SCM integration at all for it to run.

All comments greatly received, especially from the Cruise team!! :)

Hey Karym

Thanks for trying out Cruise.

The short answer is that Cruise doesn’t support working without SCM integration, and it’s not something we’ll be supporting any time soon.

You’re right – you don’t need SCM integration to run a script. But my question is: why wouldn’t you use SCM? There are so many free SCM tools on the market today, including (for example) Mercurial which allows you to get up and running in literally seconds with a couple of commands. The benefits are enormous. In particular, if you’re doing continuous integration, you want your CI server to run on a different box from your development machine – that’s the whole point of CI. Given this requirement, an SCM tool is going to be necessary anyway (unless you want to manually copy files over, which is more work than using an SCM).

If we don’t support your favourite SCM tool, that’s another thing—we’ll be adding support for other SCMs over the coming months.

Thanks,

Jez.

Well, without a non-SCM way to trigger a pipeline, transitions to Cruise will be a very tough sell—especially to enterprises.

Why? No way to incrementally insert Cruise anywhere other than the front end of the process. This disruptive displacement is too much for most shops I’ve worked in. If I have to shift SCM systems just to try out Cruise, it ain’t gonna happen, no way Jose. Kluging up phantom check-ins to tell Cruise that a certain file it can already see just changed, brings up unnecessary skepticism and queries about “what other sensible process integrations does it not do”.

Can I force a pipeline via the RESTful API? That would suffice. I’d write a script to check what I want, and trigger only when needed. Run that script from a cron-job once a minute, and we’re good to go adding “onto the end” or “onto the side” of our existing processes. (Far more acceptable than “replacing the front” while production continues.) Most communicative would be for that pipeline to have zero materials (!) to reflect it’s an external-trigger-only pipeline.

mull mull ….

It would be silly not to support this. We currently use TeamCity to automate dev db snapshots. It does this once a day on a schedule and has nothing to do with source control. It’s not because we don’t want to use source control, its because it doesn’t need source control.

@Joseph, Aaron—it seems to me that you are talking about something different from Karym.

Karym, I think, is talking about being able to do jobs from the filesystem, rather than from source control. To support this on a grid architecture, we’d need either for the user to set up a filesystem share on every agent and tell Cruise where it is, or have some mechanism for sending bits of filesystem over the wire. Since source control systems do this job perfectly well, we aren’t planning to support Cruise without SCM support.

However, the issue of triggering a build is a separate one.

@Joseph: It is possible to trigger builds programmatically with Cruise – you have to POST to the following URL: http://hostname/cruise/pipelineStatus.json?pipelineName=[pipelineName] . This isn’t part of the public API right now – we’ll be changing the URLs to be more RESTful as part of the next release—but you can use it for now if you want to run builds off cron or something. Of course, Cruise will still trigger off source control modifications – again, there will be an option not to do this in the next release.

@Aaron: it sounds like you are basically using TeamCity as a distributed cron. That’s an interesting use case I hadn’t considered, and one we’ll support for the next release (along with multiple materials, which is also not yet supported).

+1 for Aaron’s use case; we don’t do it currently, but we’d like to.