In a repository with dependencies
e.g. `odoo-dev/enterprise` depending on `odoo-dev/odoo`
consider a build as a duplicate of another if
- The HEAD is identical (as before)
- AND the branches used for the depending repositories are the same
e.g.
- pushing `master-staging-dle` to `odoo-dev/enterprise`,
- with as HEAD the same HEAD than `master`,
- but for which a branch `master-staging-dle` exists in `odoo-dev/odoo`
- a duplicate would be a build having as HEAD the HEAD of master
AND the `odoo-dev` branch `master-staging-dle`
Before, it would have used the latest build of the `master` branch,
as the HEAD was the same, despite the fact it didn't use the branch
`master-staging-dle` of `odoo-dev/odoo`
The `git gc --auto` command often fails and requires an explicit
execution of `git gc --prune=all`. When it happens, it crashes the
update, failing the cron execution.
Executing `git gc prune` every time would be very slow and dispruptive
during the cron's critical sections.
As the initial goal was to avoid triggering the automatic GC during the
next update/pull command, we prefer to adopt the global strategy of
disabling the auto GC globally with:
git config --global gc.auto 0
And to configure a system cron job to periodically GC/prune all
repositories, to get the performance benefit.
Due to locking issues, that cronjob should be scheduled outside peak
build hours.
Example bash script for the system cron:
```
#!/bin/bash
set -e
base_repo_dir='/path/to/runbot/static/repo'
for repo in $base_repo_dir/*
do
if [[ -d $repo ]];then
git --git-dir="$repo" gc --prune=all
fi
done
```
Catch exceptions occurring within job methods, to avoid
stalling the runbot by repeatedly trying to call it -
and crashing every time.
Mark the build as failed immediately and skip it.
Most of the non-CRUD methods of runbot models should be private, as
there is no need to access them via RPC.
WARNING: This change is backwards compatible with existing
installations and existing runbot databases, but will most
likely BREAK all third-party extensions, due to the renamed
methods.
Fortunately the runbot module is not ruled by Odoo's "stable policy" ;-)
Reported by @nilshamerlinck - thanks!
When doing a `git archive`, all the files in the tar archive are set to
the commit date. Ignore this date during extraction.
Having the files with dates in future will make some tests about assets
to fail. These tests force the asset regeneration by `touch`ing one
js/css file. If other bundle files are still older that the one we touch,
the asset is not regenerated and the test fail.
This commit() is the root cause of the famous false-positive error
`_check_module_names invalid module names, ignored: False`.
The first step (pull code) is a long one. if a push-hook request
happen during this step, the current transaction wont be able to be
commited (the list of module to test is written on the build). Due to
this early commit(), the build is left in an intermediate state with
the module list unpopulated (=False).
To find out the list of manually created dbs,
rev. 4d94f45 used the cursor that is connected to the
master `runbot` database, which may reside on a different
cluster/host.
- Add a helper to run commands on the local PG cluster
instead ("postgres" database).
- Modify other commands for local cluster (create/drop db)
to use the same cursor. Rename those methods to _local_*
to better indicate their local effect.
- pos_blackbox_be: because it makes the POS unuseable without a blackbox
- pos_cache: because it's too confusing for runbot users, everytime they
update a product they have to also update the cache, but
most people don't realise that.
As of Odoo 9 the first l10n module installed will automatically
install its chart of account on the main company, so installing
the first one (l10n_ae) is surprising/strange.
Branches that want to build l10n_* modules should list
them explicitly in the "modules to install" field (modules).
In addition, having demo data to set the country of the
main company will automatically installe the relevant
l10n module if it exists. This is the default in Odoo 9
with l10n_us.
This allows configuring an explicit list of modules to install
on a repository without having orange builds (with warnings)
whenever a branch does not have one of these modules for some
reason.
This lets us use them in README files
on GitHub, which uses an image proxy
that does not have access to private
repositories.
This is an acceptable disclosure of
information about private repos.
The web addon is supposed to be duplicate, and needs to be installed
(in the enterprise version) over the community edition.
A better fix would be to keep the folder and use the --addons-path key
to start the server with the correct addon, but this is an urgent
change.
closes#69
pushing new commits on your branch should not make you loose rank in schuler
build order is based on sequence which is the id of the build, take lowest
When a build is skipped, `build.host` is `False`.
The proposed link is then just `http://rubot/static/build/...` which is invalid.
As there is no logs anyway, hide the buttons.
The base field is used to compose URL (e.g. "https://%s/pulls" % repo.base).
The URL given by github can contains trailing '.git' so this should be removed.
This module should be simply deleted in a futur version.
The implementation are not more supported with Odoo.
Architecture need to be reviewed to allow the support of this library
c6ce286 moved cla check as first job (`05_check_cla`), but as the
checkout of the working directory was done in `10_test_base`, the check
was actually a no-op.
Do the build environment init in `job_00_init`.
Jobs that does not returning a pid to wait for are automatically
rescheduled.
/b/ :
Use smallest repo_id by default if repo is not specified
Allow to force the repo in quick_url /b/<branch_name> -> /<repo>/<branch_name>
Duplicated:
If state is duplicated, the main build in not always running
There was an uncaught exception raised by one of the git command in certain cases when searching for the right branch in the dependencies repositories. Because of this error, the dependencies process never finished, and in some case there was no server to run because the server was located on a dependency repo. With no server to run, the build would fail instantly at the start of the testing phase.
revert commit dea869273a9a03f6f58993c3fa558a916cb8e4a5
phantomjs stderr is now discarded since odoo commit
5a642a802e
no need to discard odoo stderr from logfile.
Close#49
