runbot/runbot/models/ir_cron.py

import odoo
from dateutil.relativedelta import relativedelta

from odoo import models, fields

odoo.service.server.SLEEP_INTERVAL = 5
odoo.addons.base.models.ir_cron._intervalTypes['seconds'] = lambda interval: relativedelta(seconds=interval)


class ir_cron(models.Model):
    _inherit = "ir.cron"

    interval_type = fields.Selection(selection_add=[('seconds', 'Seconds')])
[IMP] runbot: replace jobs by build configs This commit aims to replace static jobs by fully configurable build config. Each build has a config (custom or inherited from repo or branch). Each config has a list of steps. For now, a step can test/run odoo or create a new child build. A python job is also available. The mimic the previous behaviour of runbot, a default config is available with three steps, an install of base, an install+test of all modules, and a last step for run. Multibuilds are replace by a config containing cretaion steps. The created builds are not displayed in main views, but are available on parent build log page. The result of a parent takes the result of all children into account. This new mechanics will help to create some custom behaviours for specifics use cases, and latter help to parallelise work. 2019-04-22 20:49:33 +07:00			`import odoo`
			`from dateutil.relativedelta import relativedelta`

			`from odoo import models, fields`

			`odoo.service.server.SLEEP_INTERVAL = 5`
[REF] runbot: adapt cron path 2020-01-02 22:28:38 +07:00			`odoo.addons.base.models.ir_cron._intervalTypes['seconds'] = lambda interval: relativedelta(seconds=interval)`
[IMP] runbot: replace jobs by build configs This commit aims to replace static jobs by fully configurable build config. Each build has a config (custom or inherited from repo or branch). Each config has a list of steps. For now, a step can test/run odoo or create a new child build. A python job is also available. The mimic the previous behaviour of runbot, a default config is available with three steps, an install of base, an install+test of all modules, and a last step for run. Multibuilds are replace by a config containing cretaion steps. The created builds are not displayed in main views, but are available on parent build log page. The result of a parent takes the result of all children into account. This new mechanics will help to create some custom behaviours for specifics use cases, and latter help to parallelise work. 2019-04-22 20:49:33 +07:00
[IMP] runbot: runbot 5.0 Runbot initial architechture was working for a single odoo repo, and was adapted to build enterprise. Addition of upgrade repo and test began to make result less intuitive revealing more weakness of the system. Adding to the oddities of duplicate detection and branch matching, there was some room for improvement in the runbot models. This (small) commit introduce the runbot v5.0, designed for a closer match of odoo's development flows, and hopefully improving devs experience and making runbot configuration more flexible. Remotes: remote intoduction helps to detect duplicate between odoo and odoo-dev repos: a commit is now on a repo, a repo having multiple remote. If a hash is in odoo-dev, we consider that it is the same in odoo. Note: github seems to manage commit kind of the same way. It is possible to send a status on a commit on odoo when the commit only exists in odoo-dev. This change also allows to remove some repo duplicate configuration between a repo and his dev corresponding repo. (modules, server files, manifests, ...) Trigger: before v5.0, only one build per repo was created, making it difficult to tweak what test to execute in what case. The example use case was for upgrade. We want to test upgrade to master when pushing on odoo. But we also want to test upgrade the same way when pushing on upgrade. We introduce a build that should be ran on pushing on either repo when each repo already have specific tests. The trigger allows to specify a build to create with a specific config. The trigger is executed when any repo of the trigger repo is pushed. The trigger can define depedencies: only build enterprise when pushing enterprise, but enterprise needs odoo. Test upgrade to master when pushing either odoo or upgrade. Trigger will also allows to extract some build like cla that where executed on both enterprise and odoo, and hidden in a subbuild. Bundle: Cross repo branches/pr branches matching was hidden in build creation and can be confusing. A build can be detected as a duplicate of a pr, but not always if naming is wrong or traget is invalid/changes. This was mainly because of how a community ref will be found. This was making ci on pr undeterministic if duplicate matching fails. This was also creating two build, with one pointing to the other when duplicate detection was working, but the visual result can be confusing. Associtaions of remotes and bundles fix this by adding all pr and related branches from all repo in a bundle. First of all this helps to visualise what the runbot consider has branch matching and that should be considered as part of the same task, giving a place where to warn devs of some possible inconsistencies. Associate whith repo/remote, we can consider branches in the same repo in a bundle as expected to have the same head. Only one build is created since trigger considers repo, not remotes. Batch: A batch is a group of build, a batch on a bundle can be compared to a build on a branch in previous version. When a branch is pushed, the corresponding bundle creates a new batch, and wait for new commit. Once no new update are detected in the batch for 60 seconds, All the trigger are executed if elligible. The created build are added to the batch in a batch_slot. It is also possible that an corresponding build exists (duplicate) and is added to the slot instead of creating a new build. Co-authored-by d-fence <moc@odoo.com> 2020-06-03 21:17:42 +07:00
[IMP] runbot: replace jobs by build configs This commit aims to replace static jobs by fully configurable build config. Each build has a config (custom or inherited from repo or branch). Each config has a list of steps. For now, a step can test/run odoo or create a new child build. A python job is also available. The mimic the previous behaviour of runbot, a default config is available with three steps, an install of base, an install+test of all modules, and a last step for run. Multibuilds are replace by a config containing cretaion steps. The created builds are not displayed in main views, but are available on parent build log page. The result of a parent takes the result of all children into account. This new mechanics will help to create some custom behaviours for specifics use cases, and latter help to parallelise work. 2019-04-22 20:49:33 +07:00			`class ir_cron(models.Model):`
			`_inherit = "ir.cron"`

			`interval_type = fields.Selection(selection_add=[('seconds', 'Seconds')])`