Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: Issues with Travis

Archives

Contributors

Re: Issues with Travis

Re: Issues with Travis

Re: Issues with Travis

Thanks for the quick reaction. This should help while the definitive plan is drawn. More reasons for funding OCA instead of specific projects inside OCA!

FYI, we have started to experiment with GitHub actions in OpenUpgrade: https://github.com/OCA/OpenUpgrade/pull/2448

Regards.
by Pedro M. Baeza - 10:30 - 24 Nov 2020

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 Alomar
    etobella@creublanca.es
     
    Centros Médicos Creu Blanca
    Tel: 902 202 230
     
    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.




    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

    30 replies 30 replies

    • 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)
      - 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

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe



      --
      Simone Orsi

      Full 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


      Op 2/22/21 om 5:37 PM schreef Stéphane Bidoul:
      - docker images with Odoo pre-installed that are rebuilt nightly with the latest Odoo (inspired from the latest runbot Dockerfile template)
      - a minimalist GitHub action that orchestrates the thing (example a in Shopinvader repo)

      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?

      Tom

      by Tom Blauwendraat - 09:26 - 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

      1 attachments 1 attachments

      signature.asc
    • 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)
      - 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