Make the type of builder to be a parameter of the config file #3
Conversation
For now, as I have no idea of what is needed for jekyll or similar, I will just try to not hardcode more than needed. I do not want to document it since there is nothing to change for now. Maybe we will have to extend the script to do handle more than bundle install, maybe more than "install" and "build" step.
| syslog.syslog("Build of {}: bundle exec middleman build".format(name)) | ||
| result = subprocess.check_output(['bundle', 'exec', 'middleman', | ||
| 'build', '--verbose']) | ||
| command = builder_commands[config['builder']] |
There was a problem hiding this comment.
Seems you want to be able to handle different steps, which is nice.
Nevertheless I would have said:
command = builder_commands[config['builder']]['build']
There was a problem hiding this comment.
Indeed, good catch. I am also wondering if we should assume that each step will always be 1 command, or it can be more.
And I am also pondering on putting that in a yaml file, like this:
$ cat /something/middleman.yml
- build:
- "bundle exec middleman build --verbose"
- install
- "bundle install"
Can we reasonably assume that bundle would be used to install if there is a Gemfile, or that's something that could be bound to change right now (like, is the state of the ecosystem such that everybody use it, if I am not wrong ?)
There was a problem hiding this comment.
+1 for a YAML config file
I think so for the Gemfile. In this case you need to handle that future steps would need to be run using "bundle exec" (if a Gemfile was detected only).
There was a problem hiding this comment.
In fact, i wonder if we need a config file, or if we can also try to be smart and autodetect. Like, if there is a gem file and it contains middleman, then we know what to do. I can be added later however, but I wanted to dump that idea so I do not forget.
There was a problem hiding this comment.
I think some well-documented magic for simple things not requiring customization if nice. Gemfile->bundler is a simple one, no parameters needed, always the same command to run.
nevertheless there are tasks which are custom, like rh-events runs a dedicated ruby script. We may have ordering problems too (like do something before the build but after bundler).
So I guess we can defined these phases which would be enough for all cases I can think of in our current work:
- deps installation: currently bundler, maybe other things later
- pre-build hook, if exists
- build: run middleman or any method we know
- post-build hook, if exists
for maximum flexibility we could allow to not run the magic build.
maybe we could even have a single YAML file with just a list of commands to run, and have special magic command names for the smart deps install and build phase, so you could reorder or skip very easily. An missing recipe file would result into chaining these two magic actions.
---
recipe:
- ./generate_ruby_deps.pl
- AUTO_DEPS_INSTALL
- ./patch_broken_ruby_gem.rb
- AUTO_BUILD
- ./cleanup_nonfree.py
- find . -name \*.py -exec pep8 --ignore=E501,E402 {} +
There was a problem hiding this comment.
like dh_auto_*here the actions are normal commands, so you can order things as you want, or even not call the command of this step of the workflow, or pass special parameters…
well of course we do not need such complicated things here.
For now, as I have no idea of what is needed for jekyll or
similar, I will just try to not hardcode more than needed.
I do not want to document it since there is nothing to change
for now.
Maybe we will have to extend the script to do handle more than
bundle install, maybe more than "install" and "build" step.