Contributors mailing list archives
Re: How to auto pull only selected folder (addon) from multiple OCA repo into one repo.by
As a replica to Graeme:
Knowing what's coming (yes, seeing into the future ;-) ), I have concerns about the deployment philosophy of beeing part of the Dev tool.
There are Dev and Ops and, yes DevOps like a marriage between both.
But fundamentally, they are different problem sets, with (hopefully) different teams and different expertise.
Mix in the key guardian (and I don't mean technically, but organizationally), a trustful person, conscient of his responsibilities and with a minimum of a 4 eyes principle.
My model Odoo Implementor enterprise I'm describing here has minimum 50 employees, yes. But while this might not yet be true for most, isn't it where we are necessarily heading at?
Is it responsible to support mission critical infrastructure with any different setup?!?
El mar., 18 jun. 2019, 7:06 a.m., David Arnold <email@example.com> escribió:
The genesis of DockeryOdoo has one corner stone, that maybe differntiates it above the little gimmick. I just thought:- There are git submodules.- They come with git.- They maintain history (git blame as part of a productive dev workflow!).- They facilitate upstream contribution.I re-read the last point. It's so OCA, in theory! ;-)For working best and fueling contribution, it assumes well behaved repos, read: atomic repos, as the composing blocks. Currently, OCA repos are topic rather than atomic repos.A long standing proposal of mine is to atomize repos and maintain an automatically maintained virtual repository with git submodules presenting the topics in the accustomed way as they are today, referencing OCAsingulars/* under the hood, which anyone could access directly.Motto: Dare more and pure git. ;-)El mar., 18 jun. 2019, 5:02 a.m., Jordi Ballester Alomar <firstname.lastname@example.org> escribió:Kitti, that was a similar idea to what O was proposing to David. And this 'aggregated' repo could be customer specific, or generic. Thia repo is automatically built out of a YAML repo/modules specification, like most projects here use.So, +1 to your idea.Given that, I must say that we use doodba very often, and it is good. The only thing I miss is the ability to understand the code diff when you want to do a new deployment to a customer. And that's where the above apporoach can workEl mar., 18 jun. 2019 9:52, Kitti Upariphutthiphong <email@example.com> escribió:Hi everyone,While I am reading thorough all these cool options, which are about pulling addons from github from remote repo to local first, before spinning it up for use.My other, may be weird idea, is to prepare the new github repo that aggregate all the needed addons from multiple repos (and PRs), all to happen inside github itself. If there is configuration yaml file to point to source, it it might also be in that repo. I am not sure we can create some kind of bot in github to do that?In other words, a self maintained github repo that get itself updated (with predefined number of addons) as soon as the source gets updated.This way, on the server(s) that we run Odoo, we just pull from this one special github repository, without worry about having to clone or prepare so many repositories first.We try to make things tight because we want to maintain all same addons versions across projects. which we never achieved in the past.Is this sound practical / possible to you?On Tue, Jun 18, 2019 at 12:15 PM Kitti Upariphutthiphong <firstname.lastname@example.org> wrote:Love the gimmick in odooup :)On Mon, Jun 17, 2019 at 8:02 PM David Arnold <email@example.com> wrote:HiAnd there is yet another one https://pypi.org/project/odooup/It's just a tiny small wrapper around DockeryOdoo to help to init a new project. It also has a hidden gimmick :-)It doesn't use git aggregator, just plain git submodules.We found this most useful, because we can't resist at times, as a good fellow citizens, the urge to cleanly contribute back to upstream.Therefore submodules are just trump.Best Regards,David A.El lun., 17 jun. 2019, 7:52 a.m., Jordi Riera <firstname.lastname@example.org> escribió:Hello,here at Numigi, we have tested git-aggregator and while it is great, we found the relation to the git repositories to tight. Our need was to pull add-ons and to add them to a docker. As simple as that. In this regard, we built gitoo (https://github.com/Numigi/gitoo). It does what we needed, nothing more. It pulls repository in a temporary folder, remove all the git related stuff and copy the wanted add-ons to the target directory.We found in its simplicity what the company needed, and even some of our clients now us it.It is open source and all the feedback/pull requests are welcome.Hope it helps,JordiLe lun. 17 juin 2019 à 04:32, David Beal <email@example.com> a écrit :Hello kitti,Thanks to Pedro to present most of the tools. It seems they all use https://github.com/acsone/git-aggregatorSome of them are all in one solutions, but for your particular problematic I confirm it can be solved by symbolic links.You can have a look to this libDoc is not fully and update documentedBut here is the format you need to exposeYou see the format for merged branch and how to specify which modules (account-fin ...) are collected to 'links' directory gather all symbolic linksaddons path is then only : /odoo/src/addons', '/odoo/src/odoo/addons', '/odoo/links', '/odoo/local-src'finally `ak build` cmd : generate a repo.yaml file required by git aggregator which clone and update branchLet me know if you need informationMy 2 cts
David BEAL - akretion.comChef de projetOdoo Développement / IntégrationLe lun. 17 juin 2019 à 08:22, Kitti Upariphutthiphong <firstname.lastname@example.org> a écrit :Thanks you Pedro, I will take a good look at it.At first I was thinking about using Apache Airflow to automate git things (also to explore other aspect).On Sun, Jun 16, 2019, 6:07 PM Pedro M. Baeza (Tecnativa) <email@example.com> wrote:Hi, Kitti,With "manual" deployments, it's difficult to handle all the possible needs you have for an Odoo installation. Before created a deployment system, what I did is to git clone full repos, and add in the addons path only one extra folder, in which I made symbolic links of each addon I want to put in the database. With that, you only need to do git pull on each repository for updating it, but symbolic links will keep the same number of addons.But then, pull requests come to be important also, because you can't wait for the PR to be merged for having it in the installation. And also to auto-update concerning addons, and to have staging environment...So we created Doodba (DOcker ODoo BAse) as a general solution for deployment: https://github.com/Tecnativa/doodba. It includes all the tools that our know how have recommended over the time, with all these questions solved: we have an addons.yaml file where you declare the repository and the addons, and they are auto-populated. You can put in repos.yaml possible pull requests and they will be auto-merged in your deployment. Auto-update, protected staging environment, Mailhog for checking outgoing mails, etc is the set of features you have.For not being promoting only my solution, I have to say that other deployment methods have been done by other felow companies that are OCA contributors, like the pip system, packaging modules as pip packages and being able to do `pip install`, or other Docker based solutions like Dockery, Akretion docker-odoo or Camptocamp docker-odoo-project. Sorry if I miss any other one, but this is what I have in my head right now. Any other project can be mentioned as reply.Regards--
Ecosoft Co. Ltd., Kitti Upariphutthiphong