Contributors mailing list archives
Re: Runbot long term to install packages and other featuresby
I'm agree with you.
We need fix the good points mentioned.
We recently have created the travis2docker release 3.0 where some issues are fixed.
But we need work to make it semi-perfect and we prefer work on this if we have the OCA approval and feedback of reviewers to create it better.El 07/08/2016 4:58 p.m., "Dave Lasley" <firstname.lastname@example.org> escribió:We have been running a Dockerized Runbot at LasLabs since around the time we wrote that Bamboo article, and I would have to agree that it has significantly cut down on our administrative overhead.Even though I am fully supporting this initiative, I feel the need to play devil’s advocate. Every good thing comes with a tradeoff and that is also the case here. Following are some issues we have run into, most of which are fixable easily:
- I’m not totally privy on hard drive usage w/ normal Runbot, so maybe this is an issue there as well, but the Docker images are being stored beyond instance termination. This has been great from a debugging perspective, but does bring up some scaling concerns when deployed at OCA level
- Along the same note of hard drive, obviously the builds are larger in general (~2.5GB + db) due to container overhead. It would probably be possible to slim the base system down, but there will still be the overhead
- A lot of the existing OCA Travis configs are not compatible, and will skip builds due to lack of TESTS=1 matrix
- Build logs are not dropped into Odoo DB & subsequently displayed on the log page
- We had an instance with some dumb config settings on the base Odoo instance, which caused it to restart at one point. While the instances are destroyed in Runbot as they normally would be, the restart unhooked them from their Docker instances, which resulted in a bunch of straggling instances using ports that were then used on subsequent builds.
- This seems fixed on Vauxoo’s Runbot, but our’s is outputting colorized logs in core. This causes false positives on builds that are catastrophically broken, such as a missing import - note how there is still a coverage report below the Test Summary, which indicates a travis_after_tests_success. While the issue itself looks to be fixed in newer code & we were able to monkey patch a quick solution to make the builds red, the point here is that adding another layer does add new sets of possible failure points.With the minor gotchas stated, I would say that this solution has saved more man hours than it has caused - including our integration with internal CI like Bamboo.
Thank you,Dave Lasley - LasLabsFounder / CEO
<img height="49" width="50" src="cid:B6781F39-FEE7-4B4E-
91AD-FDB83E4A18E3@dlasley.net" >On Aug 7, 2016, at 12:49 PM, Moises Lopez <email@example.com> wrote:* HistoryA) Install packagesThe current process to install packages for our runbot for OCA is:1. Request to install pip and apt packages.2. Wait manual installing by server-admin.3. Receive the confirmation of package installed.4. Rebuild manually.Between 2 and 3 we could wait a pair of days or weeksThe worst example is https://github.com/OCA/report- print-send/issues/54(1 month).If we need of one person this delay is normal (anyone who is).But we have a requirements.txt file that we can re-use to install dependencies on runbot.B) Reproduce travis errorsCurrently we have errors from travis that we can't reproduce on local and we don't have access to the build of travis to debug that environment.Other example: https://github.com/OCA/runbot- addons/pull/53We can't reproduce this error from other environment the last one have a video of how to detect them with the same environment: https://youtu.be/r6-IE87UZQcC) Repositories dependenciesCurrently we have a runbot where we need configure manually the repositories dependencies, but we have a oca_dependencies.txt.Runbot have a method to process them and MQT have other one for travis.We can re-use it too (similar case from requirements.txt) and avoid duplicated code and re-configurate 2 times the same thing.* Proposal- PiecesThe tool travis2docker generates a Dockerfile base on .travis.yml (86% of coverage)(Our use a custom image with custom packages pre-installed and other things to make caching https://hub.docker.com/r/vauxo o/odoo-80-image-shippable-) auto/All repos of OCA are using a .travis.yml with MQT centralized.We have a odoo module runbot_travis2docker fo r version 9.0 and 94% of coverage- Join themWe have all pieces to join them to fix A) B) and C).With this pieces if you add a package from .travis.yml, requirements.txt or oca_dependencies we re-use the same code of MQT to generate the instance with all apt and pip packages, and all repositories dependencies recursively.We don't need extra custom configuration from runbot instance or server commands.FYI we have a stable runbot using on http://runbot.vauxoo.com/ru nbot(Offtopic with a isolated environment we have a ssh conexion feature to debug direclty from container if a error is hardly to reproduce locally).It's 100% is compatible with others CI like as @lasley told us hereConclusionMy proposal is migrate our current runbot to dockerized one.@Lasley @alan196 and me give you our help to configure and fix new issues.FYI @Alan196 send us a video of how configure it hereNote: We have other cool tools, but many of them require a extra file or extra configuration to work.What do you think?
Vauxoo, Moisés López Calderón