-
-
Notifications
You must be signed in to change notification settings - Fork 93
Challenging contribution: runbot_docker #38
Comments
Thanks for writing down the proposal @bwrsandman! The original runbot is a very specific tool for the needs of Odoo SA. They use it to run the tests, which I don't care about because travis & co already exist. On the other hand, it builds instances that can be tested online, which is what we do for OCA. With If we add handling of docker images like you suggest here, runbot could in theory become completely independent of odoo: whatever build system like buildout of whatever could produce a docker image, that we deploy on runbot as a multiple staging server of sorts. Then I'd like to be able to deploy the same docker images to normal servers. The different ports can be exposed via docker instead of passing manually options to odoo. At this point we'd have a nice web interface to deploy any multiple docker instances, exposing ports, at every commit/pull request. This is nice, but makes me wonder whether such a thing exists already, and if not, then it would make sense to make the effort independently of odoo. Does that make any sense? Thanks for your time! |
Technically, with It would of course mean a fork and that these addons would no longer benefit from Odoo's improvements to the base runbot. Forking is costly, and would only work if there were a lot of contributors and maintainers. I know base runbot isn't the top priority for development at Odoo, but they do have a lot more resources than the OCA has. |
FYI You can re-use the .travis.yml to auto-generate the Dockerfile. |
@bwrsandman I was still talking about the product under test. You're right, with On the other hand, thinking of the implementation, if we pull from a git repository docker images and run them exposing different ports, with a webapp that allows to login into each of them and see the logs, we're getting quite far from the original runbot. I agree on that, too. |
@moylop260 I've seen the script, thanks! Personally I'd prefer not to base my builds on the travis file, but on some other system like buildout + erppeek. Then both travis and runbot (or docker or...) can just wrap the existing system with minimal overhead. |
@lepistone Currently, we have ten diferent sides where we have that create a configuration.
Then, by each tool we need to create a additional configuration. But I'm agreed with you of don't depends directly from
oca_dependencies.txt is a good approach to this focus. Thanks for getting here, I wanted to express myself. What do you think? |
FYI |
FYI I'm working in a alpha module of runbot_travis2docker However, your feedback is welcome in fork projects. |
[FIX] runbot_travis2docker: Fix support multi ENV one-line
(Same comment from OCA/maintainer-quality-tools#313 (comment)) |
thanks |
A new module which changes the main test functions of original runbot.
Overload all functions dealing with
runbot/static/*
with the exception of the logs.An option for a base DockerFile image to simplify the build should be added to the
runbot.repo
.All builds should use the base DockerFile and clone and merge pull requests. In the job_00.
The job_10 should be based off the job_00 and job_20 should depend on job_10.
The cleanup mechanism should be transposed to clean docker images.
Find a way to optimize
repo.branch
docker files. For example, a PR on 8.0 should start with the 8.0 job_00 image and add a git fetch and merge from the PR source.Running the docker images should forward the same port inside the instance, but map it the same way it does now (in a range in 2000).
The text was updated successfully, but these errors were encountered: