Skip to content
This repository was archived by the owner on Oct 15, 2020. It is now read-only.

Make the type of builder to be a parameter of the config file #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Make the type of builder to be a parameter of the config file #3

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions files/build_deploy.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,13 @@
args = parser.parse_args()


builder_commands = {
'middleman': {
'build': ['bundle', 'exec', 'middleman' 'build', '--verbose']
}
}


def debug_print(message):
if args.debug:
print message
Expand Down Expand Up @@ -206,9 +213,9 @@ def notify_error(stage, error):
notify_error('install', C.output)

try:
syslog.syslog("Build of {}: bundle exec middleman build".format(name))
result = subprocess.check_output(['bundle', 'exec', 'middleman',
'build', '--verbose'])
command = builder_commands[config['builder']]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems you want to be able to handle different steps, which is nice.
Nevertheless I would have said:
command = builder_commands[config['builder']]['build']

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+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).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 {} +

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, why not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's like DH in some way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DH ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

syslog.syslog("Build of {}: {}".format(name, ' '.join(command)))
result = subprocess.check_output(command)
except subprocess.CalledProcessError, C:
notify_error('build', C.output)

Expand Down
1 change: 1 addition & 0 deletions templates/builder.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
name: {{ name }}
builder: 'middleman'
notification:
{% if irc_server %}
irc:
Expand Down