This repo is a kind of plugin, or module. It's not a full configuration for a buildbot instance. For deployment, you edit the instance configuration and include this module.
Yes something like that, but it should be only the buildbot-specific stuff and not the whole existing Dockerfile
Yes but we don't need to do this in this project. The master.cfg would look something like this:
parent = util.BuildFactory()
parent.addStep(steps.GitHub(
…There should be additional code for modifying the dockerfile. At the very least, it needs to install buildbot-worker and its dependencies, setup the default worker and run it in entrypoint. At the moment we can assume "apt", but in the future it should be able to detect the distro and adjust commands based on that.
I realised a problem. The code needs to be split between master and worker parts. Master code doesn't see the directories and files, and worker code doesn't have access to properties.
I think something more like the brew_package_steps from the config repo. One for adding steps for the parent BuildFactory, one for the children.
the "old" renderers (above) I would leave out of here and just keep them in the config repo. They aren't really related to this project.
Something like
c['buildbotURL'].'/change_hook/base'
the buildbotURL could be passed as an argument to trigger_child_hooks.
yes. I think for an MVP we only need repository and branch, maybe revision. For later, probably owner and owners (the way I have it setup now, it would allow people to re-run jobs for their…
multibuild.py will have to be loaded from the buildbot config, just like now it's importing lib/wine.py, for example. But it can be made into a separate pip module, for example, so it can be…