Running pipelines without material

[Diogo Serra]

Hello guys,

First of all, congrats on this awesome tool!

I was wondering, is there any reason why every pipeline needs at least one material to be specified? I was thinking about using Go for automated backups of tools/elements, thing that you can achieve via command line (e.g. repositories, trac, databases, etc). This way everything could be fully automated, and since any server can have an agent, this would be particularly useful.

Give me some thoughts on this, best practices, and if you think Go is the tool for this task.

Thanks in advance!

[Kevin Wright]

If fixed this by creating a "null" git repository, no files contained, never changes, single empty commit.  Then flagged the pipeline to also not fetch material.

Works just fine!

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Marius Ciotlos]

This would be a very nice feature. Can this be considered?

I have also thought of GO as a nice workflow tool as well. It has all the flexibility it needs.

Things that are missing:

- Not relaying always on materials

- Having a way (just like trigger with options), to trigger with specific params. 

Cheers, 

Marius

[Jens Rantil]

Diogo,

It sounds like you are trying to use go.cd for something that it was not built for. Have a look at a remote execution engine like Saltstack[1] which I think would suit you better.

[1] http://www.saltstack.com/

Cheers,

Jens

[Rustin Daniels]

Hi Diago,

On many build pipelines i've always had 'management/admin' pipelines which I use for many tasks eg. relational database high availability bootstrapping, backups, installation of compilers, tools, setting up certs,scheduled task installation etc.

It works very well and a very clean solution I can tear down the infrastructure spin up fresh instances and with the autoregistration.properties you bootstrap agent into and environment and assign jobs by specifying resources in the properties file when the agent comes online it automatically picks up configuration jobs.

The only problem is that its not a scalable solution also not what all the cool kids are using lately. The other problem you would be faced with is the Go server can only handle 'so many' agent on its grid before it runs out of steam, I'm however not sure of the exact max numbers tho.

I would say be as creative as you can when using Go. You could use it to configure/manage a director host for example to run ansible or salt stack for environment configuration that way you version control your configuration and software you use to manage your infrastructure.

As for empty materials, for the very least you would need a tools and build folder as part of your upstream dependency to every build pipeline and try not to run adhoc cmd scripts from go. Instead create build scripts version them and your tools folder. Create jobs that execute build targets, use macro definitions that way you can re-use commands with variable input.

Regards,

Rustin