Archives
Contributors
Re: Issues with Travis
Hi Holger,
Yes that approach can work too.
TBH, I was hoping to take the occasion of moving out of travis to simplify things a little bit.
A few weeks ago I had progressed with my experiment and these days we are testing it in the Shopinvader organization.
It looks like this:
- docker images with Odoo pre-installed that are rebuilt nightly with the latest Odoo (inspired from the latest runbot Dockerfile template)
- 3 very simple scripts to install addons and their dependencies, initialize the test database and run tests
- a minimalist GitHub action that orchestrates the thing (example a in Shopinvader repo)
It's lean, seems to work well and is pretty fast, as the installation step is reduced to the minimum (i.e. downloading the docker image).
In terms of the general mechanics, I have only one open question: can we rely on the Odoo exit code to detect test failure or do we still need a log parser ?
And the missing part is the small step that pushes .pot updates to git after test success.
If people agree, the rough next steps I would propose would be as follow:
- move the oca-ci repo with the container images to OCA
- add OCB builds of the oca-ci containers
- update oca-addons-repo-template with the test workflow for the 14.0 branches
- deploy it to the 14.0 branches, in parallel with Travis, and configure the merge bot to ignore the GitHub actions failures: this step will let people test it, find corner cases etc
- when all good and when runbot is ready to work without runbot_travis2docker, remove travis on the 14.0 branch
- think about older branches: the concept will work, I'm sure (I've tested 10, 12, 13, 14 and 8 should work too), but the deployment has to be organized
-sbi
On Wed, Feb 17, 2021 at 10:57 PM Holger Brunn <mail@hunki-enterprises.com> wrote:
> (some ideas in an example here > https://github.com/acsone/mis-builder/pull/3). I'm working on something more in line with current MQT in https://github.com/hbrunn/social/actions/runs/576195231 which looks pretty promising to me. Speed is an issue here, but I think this can be improved with more caching. Where should we discuss which way to go? Maybe better on an issue on MQT? -- Your partner for the hard Odoo problems https://hunki-enterprises.com_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 05:36 - 22 Feb 2021
Reference
-
Issues with Travis
Hi,I have been checking that lately Travis is getting slower to start a job. After checking, I think the problem is that travis has less available jobs, as you can check on https://www.traviscistatus.com/#day. I am not sure if this is a strategy for them or just a complication, but it seems consistent in the last month. For example, yesterday, there were 9.091 jobs at 7:40 on backlog and it took 6 hours to stay without backlog. I am not sure how much time took a job on backlog, but I am pretty sure it could be waiting two or three. Obviously, this kind of problems are annoying, as merging a PR can takes hours (and I cannot imagine what happens if we try to merge two PRs on the same branch).In order to avoid this problem, today I was able to use Github Actions with minor changes on maintainer-quality-tools.Has anyone tried to do something on this line? Has OCA checked other options?Kind regards,Enric Tobella Alomaretobella@creublanca.esCentros Médicos Creu BlancaTel: 902 202 230Tanto este mensaje como los documentos que, en su caso, lleve como anexos,
pueden contener información reservada y/o confidencial, destinada exclusivamente
para el uso del destinatario o la persona responsable de entregarlo al mismo,
estando su uso no autorizado prohibido legalmente.
Su contenido no constituye un compromiso para Creu Blanca (la empresa remitente)
salvo ratificación escrita por ambas partes. En caso de su recepción por error,
rogamos nos lo comunique por igual vía, se abstenga de realizar copias del mensaje
o documentos adjuntos, remitirlo o facilitarlo a un tercero, y proceda en su defecto,
a su eliminación.
Tanto este mensaje como los documentos que, en su caso, lleve como anexos,
pueden contener información reservada y/o confidencial, destinada exclusivamente
para el uso del destinatario o la persona responsable de entregarlo al mismo,
estando su uso no autorizado prohibido legalmente.
Su contenido no constituye un compromiso para Creu Blanca (la empresa remitente)
salvo ratificación escrita por ambas partes. En caso de su recepción por error,
rogamos nos lo comunique por igual vía, se abstenga de realizar copias del mensaje
o documentos adjuntos, remitirlo o facilitarlo a un tercero, y proceda en su defecto,
a su eliminación.
by Enric Tobella Alomar - 07:00 - 22 Oct 2020-
Re: Issues with Travis
Thank you Stéphane, it sounds like a good plan!On Mon, Feb 22, 2021 at 5:37 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:Hi Holger,Yes that approach can work too.TBH, I was hoping to take the occasion of moving out of travis to simplify things a little bit.A few weeks ago I had progressed with my experiment and these days we are testing it in the Shopinvader organization.It looks like this:- docker images with Odoo pre-installed that are rebuilt nightly with the latest Odoo (inspired from the latest runbot Dockerfile template)- 3 very simple scripts to install addons and their dependencies, initialize the test database and run tests- a minimalist GitHub action that orchestrates the thing (example a in Shopinvader repo)It's lean, seems to work well and is pretty fast, as the installation step is reduced to the minimum (i.e. downloading the docker image).In terms of the general mechanics, I have only one open question: can we rely on the Odoo exit code to detect test failure or do we still need a log parser ?And the missing part is the small step that pushes .pot updates to git after test success.If people agree, the rough next steps I would propose would be as follow:- move the oca-ci repo with the container images to OCA- add OCB builds of the oca-ci containers- update oca-addons-repo-template with the test workflow for the 14.0 branches- deploy it to the 14.0 branches, in parallel with Travis, and configure the merge bot to ignore the GitHub actions failures: this step will let people test it, find corner cases etc- when all good and when runbot is ready to work without runbot_travis2docker, remove travis on the 14.0 branch- think about older branches: the concept will work, I'm sure (I've tested 10, 12, 13, 14 and 8 should work too), but the deployment has to be organized-sbiOn Wed, Feb 17, 2021 at 10:57 PM Holger Brunn <mail@hunki-enterprises.com> wrote:> (some ideas in an example here > https://github.com/acsone/mis-builder/pull/3). I'm working on something more in line with current MQT in https://github.com/hbrunn/social/actions/runs/576195231 which looks pretty promising to me. Speed is an issue here, but I think this can be improved with more caching. Where should we discuss which way to go? Maybe better on an issue on MQT? -- Your partner for the hard Odoo problems https://hunki-enterprises.com
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.
by Simone Orsi - 11:26 - 3 Mar 2021 -
Re: Issues with Travis
On Fri, Feb 26, 2021 at 9:23 AM Tom Blauwendraat <tom@sunflowerweb.nl> wrote:Beginner's question, but do the Docker containers then run on Github's servers (as a replacement of Travis' servers currently) or on OCA servers?They'd run on GitHub servers, although GitHub allows self hosted runners if we want to.Or, if the need arises again in the future, switch more easily to any another CI runner.-sbi
by Stéphane Bidoul - 09:31 - 26 Feb 2021 -
Re: Issues with Travis
> - a minimalist GitHub > action that orchestrates the thing ( example a in Shopinvader repo [5] ) > It's lean, seems to work well and is pretty fast, as the installation step > is reduced to the minimum (i.e. downloading the docker image). this I think is the killer feature. And as you describe the transition period below, we'll have enough time to iron out corner cases; preserving the amount of work we put into this was my main reason to try to salvage current MQT > In terms of > the general mechanics, I have only one open question: can we rely on the > Odoo exit code to detect test failure or do we still need a log parser ? the exit code is trustworthy to my knowledge https://github.com/OCA/OCB/blob/14.0/odoo/service/server.py#L1229 and similar code exists more or less forever already. Isn't the log parsing done by runbot to also error out on warnings and give early notice when it fails? > If people agree sounds perfectly fine to me > - think about older > branches: the concept will work, I'm sure (I've tested 10, 12, 13, 14 and 8 > should work too), but the deployment has to be organized I personally am not willing to invest work in the py2 versions, but don't see a reason why others shouldn't work on this. -- Your partner for the hard Odoo problems https://hunki-enterprises.com
by Holger Brunn - 06:21 - 22 Feb 2021 -
Re: Issues with Travis
Hi Holger,Yes that approach can work too.TBH, I was hoping to take the occasion of moving out of travis to simplify things a little bit.A few weeks ago I had progressed with my experiment and these days we are testing it in the Shopinvader organization.It looks like this:- docker images with Odoo pre-installed that are rebuilt nightly with the latest Odoo (inspired from the latest runbot Dockerfile template)- 3 very simple scripts to install addons and their dependencies, initialize the test database and run tests- a minimalist GitHub action that orchestrates the thing (example a in Shopinvader repo)It's lean, seems to work well and is pretty fast, as the installation step is reduced to the minimum (i.e. downloading the docker image).In terms of the general mechanics, I have only one open question: can we rely on the Odoo exit code to detect test failure or do we still need a log parser ?And the missing part is the small step that pushes .pot updates to git after test success.If people agree, the rough next steps I would propose would be as follow:- move the oca-ci repo with the container images to OCA- add OCB builds of the oca-ci containers- update oca-addons-repo-template with the test workflow for the 14.0 branches- deploy it to the 14.0 branches, in parallel with Travis, and configure the merge bot to ignore the GitHub actions failures: this step will let people test it, find corner cases etc- when all good and when runbot is ready to work without runbot_travis2docker, remove travis on the 14.0 branch- think about older branches: the concept will work, I'm sure (I've tested 10, 12, 13, 14 and 8 should work too), but the deployment has to be organized-sbiOn Wed, Feb 17, 2021 at 10:57 PM Holger Brunn <mail@hunki-enterprises.com> wrote:
> (some ideas in an example here > https://github.com/acsone/mis-builder/pull/3). I'm working on something more in line with current MQT in https://github.com/hbrunn/social/actions/runs/576195231 which looks pretty promising to me. Speed is an issue here, but I think this can be improved with more caching. Where should we discuss which way to go? Maybe better on an issue on MQT? -- Your partner for the hard Odoo problems https://hunki-enterprises.com
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 05:36 - 22 Feb 2021
-