Commit Graph

546 Commits

Author SHA1 Message Date
Christophe Monniez
d7c7e547d4 [FIX] runbot: write build results in a separate job
When a build reach the job30_run method, results from a previous testing
methods are computed.
With the previous commit 8c73e6a901 this
job can now be skipped. In that case, the results are not set.

With this commit, the results are computed in a separate method.
2019-01-23 16:10:59 +01:00
Christophe Monniez
2e05c56354 [FIX] runbot: prevent build creation on job_type none
Since 8c73e6a it's possible to skip jobs from a build by using the
job_type field on the branch. If a branch job_type is set to 'none', the
builds are created but they stay in 'pending' state.

With this commit, the build is not even created if the 'job_type' is
'none'.
2019-01-23 14:38:29 +01:00
Xavier Morel
8c73e6a901 [IMP] runbot: add a job_type on branch and build
Since the runbot_merge module, some branches does not need to be built.
For example the tmp.* branches.
Some other branches does need to be tested but it could be useless to
keep them running. For example the staging branches.
Finally, some builds are generated by server actions during the night.
Those builds does not need to be kept running despite the branch configuration.

For example, the master branch can be configured to create builds with
testing and running but nightly multiple builds can be generated with
testing only.

For that purpose, this commit adds a job_type selection field on the
branch. That way, a branch can be configured by selecting the type of
jobs wanted.
A same kind of job_type was also added on the build that uses the
branch's value if nothing is specified at build creation.

A decorator is used on the job_ methods to specify their job types.
For example, a job method decorated by 'testing' will run if the
branch/build job_type is 'testing' or 'all'.
2019-01-22 14:18:58 +01:00
Christophe Monniez
8ef9eafc60 [IMP] runbot: get the logdb uri from a config parameter
When a build is created, the --log-db command line argument is built
using the same db and credentials that the one used by the runbot.

With this commit, this argument is built based on a postgress connect
URI given as ir.config_parameter in the settings.

A dedicated role must be created beforehand on the runbot postgresql
server, accordingly to the given URI.

Also, care should be taken to give minimal privileges to this user only
granting "update" on the table ir_logging_id_seq and
"insert,select,udpate" on the table ir_logging.
2019-01-18 09:43:56 +01:00
Christophe Monniez
989513801a [FIX] runbot: find docker gateway for build smtp host
When a build is running, the stmp is the localhost.
Since Docker builds, the localhost is the container which does not catch
port 25 smtp. Mails are lost in the limbo.

With this commit, the default gateway of the Docker network is used as
smtp host for the builds. It's the responsability of the runbot host to
catch smtp traffic from the container.

This bridge interface exists by default on a system where Docker is
running. However, Docker is affected by this issue:
https://github.com/moby/moby/issues/26799

The first time the Docker daemon is installed, the Gateway is not
defined on the bridge interface. When the Docker daemon is restarted,
the gateway is correctly defined. Pay attention that restarting the
Docker daemon will kill all the running/testing builds.
2019-01-11 10:23:27 +01:00
Christophe Monniez
4c0cd91914 [REF] runbot: use Docker containers for builds
When building Odoo, the instance is started on the same host as the
runbot. It means that all the required python packages have to be
installed on each runbot hosts with the same versions. Also there is no
real separation between builds. Finally, from a security point of view,
arbitrary code could be executed on the runbot host.

With this commit, the runbot uses Docker containers to build Odoo.
During the tests, Odoo http ports are not exposed to the outside,
meaning that nobody could interact with that instance.

The Docker image used for containers is valid for Odoo branches 10.0,
11.0, 12.0 and master.

When building, right before starting the Odoo tests, the tested branch's
requirements.txt is now taken into account to adapt the container.

On a runbot host, the "docker ps -a" command can be used to have the
list of the current builds. The containers are named using the build
dest field and the current running job. For example:
  123456-12-0-123456_job_30_run

Prerequisites:

Docker have to be installed on the runbot hosts and the user that runs
the runbot should be able to use Docker. Typically, the runbot user have
to be added to the docker unix group.

On the first build, the Docker image will be built from scratch. It
can last several minutes locking the runbot cron during this time.
It means that on a multi-runbot configuration, this process will be
repeated for each runbot and during this time there will be no builds.

To avoid such a situation, the Docker image can be built from the
command line. The container.py file can be started like this:

  python3 container.py build /tmp/build_dir

The /tmp/build_dir directory will be created to store the Dockerfile.

When the process is done, the "docker images" command should show an
image tagged runbot_tests in the odoo repository. At that time, the
runbot instance can be started, it will use this image for the builds.

Api change:

The 'job_*' methods signature has changed, the lock_path is not needed anymore.

Docker image informations:

Currently, the Docker image is built based on Ubuntu bionic to
benefit of the python 3.6 version.

Chrome and phantomjs are both installed.

The latest wkhtmltopdf (0.12.5) is installed as recommended on our wiki:
https://github.com/odoo/odoo/wiki/Wkhtmltopdf
2019-01-02 11:32:04 +01:00
Christophe Monniez
a0dd87e45b [FIX] runbot, runbot_cla: notify each repo of cla status
When a PR is a duplicate of a branch, only the branch CLA status are
update. The same issue for build status was fixed in commit 4f1a55da9.

With this commit, there is new method than can be used in runbot_cla.
This method updates commit given status in each repo.
2018-12-07 09:43:16 +01:00
Christophe Monniez
4f1a55da9b [FIX] runbot: reduce the amount of github status
When commit is built serveral times, each time the status is updated, a
request is sent to github for each build.
As a side effect, if the first build is a failure and the last one a
success, github is wrongly updated to failure.
This bug is particulary annoying on PR in conjunction with the
runbot_merge, preventing a the PR to be merged even after several
rebuild.

With this commit, only the latest build per repository is used to update
the github status. The amount of github status updates is also reduced.
2018-12-06 10:53:45 +01:00
Christophe Monniez
248d23c2d0 [FIX] runbot: remove typo 2018-11-29 16:53:10 +01:00
Christophe Monniez
922be0a594 [FIX] runbot: split _get_branch_url again to avoid mass recompute 2018-11-29 16:48:34 +01:00
Christophe Monniez
c14b864b06 [FIX] runbot: fix branch infos singleton 2018-11-29 16:31:38 +01:00
Christophe Monniez
1330d52098 [REF] runbot: store the target branch name
In the case of PR, the name contains 'refs/pull/3175', the branch_name
contains '3175' and because of the previous fix e095170f8c, the
pull_head_name sontains something like 'blah:12.0-something'.

In that case, the _get_closest_branch_name reaches the fallback.

With this commit, the target_branch_name is stored in a new field and is
used as the fallback.
2018-11-29 16:18:33 +01:00
Christophe Monniez
e095170f8c [FIX] runbot: build PR with corresponding community PR
When searching for a matching PR in a target repo, the match was made on
the 'base ref' which is the base branch that the PR targets.
This means that the second case of the _get_closest_branch method was
never reached.

Example:
    An enterprise PR is created that targets Odoo branch 12.0 but with a
    matching community PR with a branch with the same name.
    The corresponding PR is never found by the runbot because the first
    rule match: '12.0' is the base ref of the PR.

This could have been fixed by using the branch pull_head_name field to
build the domain but that leads to a problem with the second rule:

If a PR branch is named 'patch-1', the domain will match each PR with
the same pull_head_name.

With this commit, the pull_head_name field will store the pull head
label. It's not a problem with older PR as a newly created PR in
enterprise will not accidentally match with older ones.

Another issue appeared with github branch naming like 'patch-'.
If someone creates a PR with a branch auto-named 'patch-1',
targeting the community repo and later creates an unrelated PR,
targetting another repo depending of the community, they will be
matched.

To avoid that, the pull head names that ends with 'patch-n' are not
stored. Those pull requests will be built against the target branch
head.

The actual behavior, before this commit, is a blocking point for the
runbot_merge which is based on PR's only. It means that when a community
PR is wrongly matched with with an enterprise PR runbot_merge will not
merge the PR's.
2018-11-28 15:28:38 +01:00
Christophe Monniez
439e336a2f
[FIX] runbot: store pull_head_name on branch
This one flew under the radar because it only affects a PR when its
branch name changes.

Closes #47
2018-10-19 08:50:20 +02:00
Christophe Monniez
070dbee204
[IMP] runbot: add priority field on branch
This commit permits to prioritize a branch when scheduling builds.
It's main purpose is for the runbot_merge module. It avoids to have
staging branches as sticky and pollutes the main repo view.
Also, that branch can benefit of the autokill feature when a newer build
is found, freeing ressources for other builds.

Closes #43
2018-10-09 16:42:34 +02:00
Andreas Perhab
3915f3d7ae [IMP] runbot: perform fetch with one git command
Closes: #33
2018-09-06 11:56:58 +02:00
Christophe Monniez
cfba7da06d
[IMP] runbot: skip an additional port for chrome
In a near future, Odoo will use Chrome Headless instead of phantomjs.
Chrome needs a port to listen to and it was decided that it will be
http_port + 2.
With this commit, we ensure that this port is not used by another build.

Closes #30
2018-08-14 13:57:31 +02:00
Christophe Monniez
52cdd9fd27
[FIX] runbot: add build type
The unicode icon added in the build subject is not clear for the users.
In that state, it's not easy to add a title on the icon or the subject.

With this commit, a build type field is added to differentiate the
builds and add the appropriate icon and title.

Closes: #24
2018-06-18 10:42:23 +02:00
Christophe Monniez
8471c8c35b
[FIX] runbot: improve coverage processing
When a build with coverage is killed during the tests, the coverage
result is set to 100%.

With this commit, coverage result is verbosely skipped if the coverage
file does not exists.

Also, the coverage module is no longer user to retrieve the coverage
value as it was already calculated. It's faster to grep the html file
than to recompute the value.

As the coverage builds takes a longer time than normal builds, the
timeout is increased for those kind of builds (as it was already done for the
CPU limit).

Finally, the omitted patterns were wrong and are now fixed with this
commit.

Closes #25
2018-06-15 13:30:04 +02:00
Christophe Monniez
822433a3bb
[IMP] runbot: add link to the latest coverage
On the frontend, the coverage is a static indication.
With this commit, this indication is now a link to the coverage details
page.

Closes: #26
2018-06-12 09:04:09 +02:00
Christophe Monniez
a3da5cad04
[IMP] runbot: increase cpu_limit
When the Odoo instances are spawned for tests, they have a time limit
set on their CPU usage. This limit is hard-coded in the _spawn method
calls.

As the number of tests are increasing, their duration increases too.
As this limit is inherited by subprocesses, if a phantomjs test
last too long, the test is killed alone.

Finally, when the coverage is enabled, the tests duration is
approximately increased of 1.5 times.

With this commit, the cpu_limit of the two main tests jobs are
increased. When the coverage is used, the cpu_limit is increased.

Closes: #23
2018-06-11 17:58:29 +02:00
Christophe Monniez
b1f155c1a2
[IMP] runbot: kill older builds when a new one is created
When a new commit is found and a new build is created, if a user
pushes more commits in the same branch a few minutes later, it causes
more builds in testing phase, resulting in a CPU waste.

With this commit, previous builds in testing phase in non sticky
branches are killed when a new build is created.

Closes: #20
2018-06-06 16:31:33 +02:00
Christophe Monniez
c6fe87e18b
[IMP] runbot: update nginx template
When someone tries to log in an old runbot build that is not running
anymore, he lands on the runbot instance that was running the build.
Also, all the running builds are allowed on all runbot instances,
leading to the same behavior.

With this commit, only the builds that are running on the runbot
instance can be reached, others are defaulted to a 404.

closes #21
2018-06-01 16:37:43 +02:00
Christophe Simonis
7fcbf6e653 [IMP] runbot: visually mark rebuilds 2018-06-01 16:31:57 +02:00
Christophe Monniez
223ba61828 [IMP] runbot: add coverage result on builds
When the coverage is activated on a branch, the coverage result is not
stored.

With this commit, the coverage result will be stored on a build.
The last result will be shown on the frontend for sticky branches.

Also, an extra_parameter field is added on the build model.
2018-05-28 09:40:01 +02:00
Christophe Monniez
46c4c54337 [IMP] runbot: force a rebuild when commit in reverse dependency
When a build fails in a repo that depends on another repo, it's difficult
to figure out from which commit it comes in the depending repo.

If this commit is applied, when a new commit is found in a repo's sticky
branch, the latest build from the same branch name, in the depending
repo will be forced to rebuild.
2018-05-28 09:40:01 +02:00
Christophe Monniez
5d23d0957a [FIX] runbot: remove deprecated method
The refresh method is deprecated and invalidate_cache should be used
instead. Also, since the new API, the cache is automatically
invalidated, hence this removal.
2018-05-28 09:40:01 +02:00
Christophe Monniez
9555370fa6
[FIX] runbot: update github status on duplicates too
Actually, when a build is a duplicate of another build, its github status is not updated.
e.g. a pull request may not have a github status but its corresponding
branch have a gtihub status.
With this commit, all builds will have their github status updated based
on the corresponding build status.

Thanks for your help @xmo-odoo 

closes: #3
2018-04-27 13:39:33 +02:00
Christophe Monniez
efbce41e2e
[IMP] runbot: choose the python version for coverage
When code coverage was processed the 'coverage' utility was called the
same way regardless of the Odoo version. That was the cause of two
problems:
1) In some OS packages, the 'coverage' executable was renamed to
'python-coverage' and 'python3-coverage'
2) Since version 11.0, Odoo needs python3

With this commit, the coverage module is called from python '-m'
argument and the python version is chosen from the Odoo executable
shebang.

closes: #12
2018-04-20 16:16:24 +02:00
Christophe Monniez
12542808a9 [IMP] runbot: log latest commit hash and message when server is built
When a server is built based on dependency_ids, only the branch refs was
logged. In this situation, it's difficult to reproduce a build locally
in the exact same conditions.

With this commit, the latest commit hash and message of this
branch is also logged.
2018-04-20 10:37:52 +02:00
Christophe Monniez
0cb07e73db
[FIX] runbot: return closest branch when PR head name are equals (#11)
When searching for the closest branch name in a target repo, if the PR
head names are equals, a branch method is called on a dictionary, causing
a traceback.

With this commit, the method is called on a branch object instance.

closes #11
2018-04-19 16:16:24 +02:00
Martin Trigaux
4a558741e0 [FIX] runbot: remove unused argument
Leftover from the old api conversion
Making an error when trying to kill a build
2018-04-10 09:02:36 +02:00
Moisés López
9de7c2f8cf [FIX] runbot: Use correct name of new parameters 2018-03-28 10:29:39 +02:00
Moisés López
8b4b941e06 [FIX] runbot: dictionary don't have iteritems attibute 2018-03-28 10:29:39 +02:00
Moisés López
a886dba4ab [FIX] runbot: Fix decode error 2018-03-28 10:29:39 +02:00
Moisés López
c9de61a320 [REF] runbot: Consider empty returned values
When installing a clean runbot instance a bad query is made because
there is not any build yet.

With this commmit, the query is not made when there are no builds
directories found on the filesystem.
2018-03-28 09:42:52 +02:00
Julien Legros
3cacd8db52
[FIX] runbot: build garbage collection 2018-03-23 14:20:34 +01:00
Julien Legros
f8cbae79e1
[FIX] runbot: nginx reload
Actually check the return code and do not raise any exception doing so.
2018-03-21 13:06:32 +01:00
Christophe Simonis
dc3659c6f1 [FIX] runbot: use connected user when logging kill/rebuild
As these methods are call in sudo mode, we should use request's user to
have a meaningful log entry.
2018-03-20 10:20:53 +01:00
Julien Legros
278d4ed449
[FIX] runbot: guess_result conversion to record api 2018-03-16 10:16:44 +01:00
Julien Legros
3d71619dcd
[FIX] runbot: make repo_id stored again
Oversight of the code migration.
2018-03-14 16:02:08 +01:00
Julien Legros
328a25a31f
[FIX] runbot: do not rely on copy behavior for rebuilds
Instead of marking most fields as `copy=False` to be able to use the
copy method for rebuilds, we create the build explicitly. We also
forbid to copy builds as it doesn't make much sense to begin with.

As for duplicates, it wasn't always possible to rebuild them. The
rebuild now injects a specific context key (force_rebuild). This allows
duplicates to undergo a rebuild. The side-effect of writing on previous
builds is also removed[1].

[1]: it's not obvious from the diff but the porting to the V8 API
should have yielded

duplicate.write({'duplicate_id': build_id.id})

instead of

build_id.write({'duplicate_id': build_id.id})
2018-03-14 15:05:17 +01:00
Christophe Monniez
e9a292373f [FIX] runbot: compute build time and don't copy from previous build
Before this commit, the job_end was always None because of a time2str
function with no return. So the job_time was the same as the job age.
Also, the result and times were copied from the prvious build. Displayed
time and results were wrong.
2018-03-13 16:38:20 +01:00
Christophe Monniez
5b8184890e [FIX] runbot: sync the build sequence with the build id
The branch order was wrong because of a zeroed build sequence.
2018-03-12 18:14:17 +01:00
Christophe Monniez
4b0eac3b21 [FIX] runbot: compute repository url 2018-03-12 17:43:24 +01:00
Christophe Monniez
21c31b4c3c [REF] runbot, runbot_cla: upgrade to Odoo 11.0
The previous code of runbot and runbot_cla was made for Odoo API version
8.0. This commit makes it work with Odoo API 11.0 and Python 3.

Also, the present refactoring splits the code into multiple files to
make it easier to read (I hope).

The main change due to Python 3 is the job locking mechanism:
Since PEP-446 file descriptors are non-inheritable by default.
A new method (os.set_inheritable) was introduced to explicitely make
fd inheritable. Also, the close_fds parameter of the subprocess.Popen
method is now True by default.

Finally, PEP-3151 changed the exception raised by fcntl.flock from IOError to OSError
(and IOError became an alias of OSError).

As a consequence of all that, the runbot locking mechanism to check if a
job is finished was not working in python3.
2018-03-12 14:36:33 +01:00