search

Olivia5k / piper

Build system that builds and very little more
http://thiderman.org/piper/
MIT License
5 stars 0 forks source link

What do with step classes? #44

Open Olivia5k opened 9 years ago

Olivia5k commented 9 years ago

The default idea is that the piper.yml file is only to supply command lines to execute. As this is the case, all of the step definitions specify class: piper.step.CommandLineStep, which is fairly repetitive. Getting rid of such boiler is pretty vital for niceness.

However, explicitness is also super nice. So, there are two things I see we could do:

Remove the ability to have different classes and only do command lines.

Pros for this is that it's cleaner and easier to maintain. Cons for this is that piper becomes less extendable.

Make it default to CommandLineStep without having to specify it.

Pros for this is that it's easy to do and keeps extendability. Cons for this is that we don't actually have a use for the extendability, yet.

I'm indecisive. @daenney, what do you think?

daenney commented 9 years ago

Drawing from pipeline-conventions and other tools that I've used I'm a big fan of just only having a command line. This means you can see exactly what happens, which commands are executed and how to reproduce them locally. There's no surprises with magical parameters or other "internal" behaviour that you need to be aware of, what's in the YAML is what gets executed.

This makes it extremely easy to reason and understand the behaviour of your builds, everything is there for everyone to see.

What I could see us do though is based on the language of the project we detect or is set pre-populate it by default with some actions so you don't have to specify anything at all. Lets say you specify Python then by default we'd run pip install -r requirements.txt and then tox and when you do Ruby we'd do bundle install followed by rake spec or something like that.

Olivia5k commented 9 years ago

All of this makes perfect sense to me! Step classes will be removed!

I've also fiddled with the idea of auto-handling things (think backend Debian...) but I think that's another issue that can be tackled at a slightly later stage!