Overview
Deployv addon: Gitlab tools. Generated by cookiecutter and cookiecutter-deploy-addon.
A small set of tools to automate repetitive tasks for testing gitlab repositories.
It is important to say that this is not by any mean a replacement for the MQT tools, these are tools that we need in order to make gitlab-ci work properly with the MQT tools.
Free software: BSD license
Installation
pip install vxci
Documentation
Development
To run the all tests run:
tox
Note, to combine the coverage data from all the tox environments run:
Windows |
set PYTEST_ADDOPTS=--cov-append tox |
|---|---|
Other |
PYTEST_ADDOPTS=--cov-append tox |
Changelog
Unreleased
clickbot: the suite also fails when an integer id, a foreign key or a sequence reached CLICKBOT_ID_CEILING_PCT percent (60 by default) of the largest value it can take, and logs the 20 fullest ones. The ceiling of an integer column fed by a bigint sequence is the integer one. CLICKBOT_ID_CEILING_ALLOWED accepts table.column items above the threshold. It reads only the catalog, the sequences and indexed maximums, so it takes seconds on large databases.
clickbot: Odoo 16.0 or later, no longer 19.0 only. The suite starts the clickbot the way Odoo’s own test of each version does (the debug services in 16.0, the module loader since 17.0), on /web or /odoo (18.0), passes success_signal only where browser_js takes it, posts the JSON-RPC call without build_rpc_payload before 19.0, reads failure_count only where ir.cron has it, and blocks the external requests of the crons in 16.0, which does not block them in tests.
check_log: when the log path holds the staggered_logs folder of a staggered_install --isolated --parallel run, every warning is reported with the install that logged it, templates included, and that install’s log, and a table of those installs closes the output. The joined odoo.log.gz_* still decides the exit status, and a warning no install log holds, such as one from another job’s log, is still reported as it is.
clickbot: new command. Restores the database a test job kept (db.pgc and filestore.tgz in CLICKBOT_DIR, $CI_COMMIT_REF_SLUG/clickbot by default) and runs the vxci_clickbot suite shipped in this package on it, under pytest-odoo with CLICKBOT_WORKERS pytest-xdist workers (4) in one job: Odoo’s clickbot over every app admin and demo see, and “Run Manually” on every scheduled action. The apps are packed into CLICKBOT_APP_BUCKETS tests (12) on the run itself, by how many menus each one has, never from a table of times; the crons into CLICKBOT_CRON_BUCKETS (8). A project tunes it with CLICKBOT_USERS, CLICKBOT_SKIP_APPS, CLICKBOT_SKIP_MENUS, CLICKBOT_SKIP_CRONS, CLICKBOT_SETUP (package.module:function hooks called with env), CLICKBOT_TIMEOUT, CLICKBOT_CRON_TIMEOUT and CLICKBOT_CURSOR_LOCK_TIMEOUT (120 s, Odoo’s 20 s is too short on a loaded runner). The verdict is pytest’s exit code and the JUnit report, written to CLICKBOT_DIR with odoo.log; a skipped test turns it red. Odoo 19.0 or later. It replaces the .gitlab/clickbot.sh and the click_all test files each project carried.
staggered_install –isolated –parallel N (STAGGERED_PARALLEL): runs the whole plan in one job, N installs at a time off one queue, instead of a share of a parallel: job fixed beforehand by staggered_costs.json. The work is done by odoo-bin-server-staggered (vauxoo/odoo-staggered) inside the instance container, the same command a developer runs locally, installed from the wheel quay.io/vauxoo/dockerv carries in ODOO_STAGGERED_WHEEL_DIR. vxci passes it the modules, ODOO_TEST_TAGS, the language, coverage around each module install, STAGGERED_KEEP_DB and --allow_deprecated, and collects the saved log, the log of every install and the coverage as before. Measured on vauxoo/ircodoo: 2868 s in one job, against 3150 s to 3364 s for the slowest of five nodes.
build_image: with ORCHESTSH=True, the image is looked up by the name the orchestsh CLI gave it (the image_name.env it writes). A main branch whose name is not VERSION (e.g. 20.0 building saas-19.4) can now set MAIN_BRANCH to push the <MAIN_APP>-<VERSION>-latest tag instead of failing with “Unable to find the recently built image”, with the orchestsh CLI before and after orchestsh/executor!366.
test_repo/test_image: with ORCHESTSH=True, instance_image is IMAGE_REPO:IMAGE_TAG when both are set (the image_name.env sourced from the build job), and is computed only as a fallback.
common: new optional ORCHESTSH_REGISTRY and ORCHESTSH_TOKEN environment variables. When the registry is set, the image notification sent to ORCHEST_REGISTRY after a push is also sent to OrchestSh, so both systems can run side by side while projects migrate. A failed OrchestSh notification is logged and does not fail the job.
staggered_install: new command that installs the modules of a repository one at a time on a single database, dependencies first and the main app last, running each module’s own tests as it is installed. A module that fails does not stop the rest. Every install runs under coverage run -p and the run combines them into .coverage_<job name>. No run asks for demo data.
staggered_install –isolated: installs each module alone on a clone of a template database holding exactly the closure of what it declares, so a module using another one it never declared fails instead of passing on what an earlier module brought in. Splits itself across the nodes of a GitLab parallel: job (CI_NODE_INDEX/CI_NODE_TOTAL), balanced with the per-module seconds of staggered_costs.json when the repository commits it. STAGGERED_KEEP_DB keeps the main app’s database. Demo data that Odoo failed to load ends the run red.
coverage: new COVERAGE_EXCLUDE_LINES environment variable to append regexes to the exclude_lines section of the generated .coveragerc. A repository can now skip a whole family of lines from its variables.sh instead of spreading # pragma: no cover comments over the source. Use \n to separate several regexes, since variables.sh only accepts single-line exports.
tools_test: fall back to Chrome for Testing when a pinned Chrome version is no longer published in the Google apt pool, which purges old builds. Keeps the older Chrome that Odoo’s legacy --headless tour driver needs installable, so browser tours stop being silently skipped with “Chrome executable not found”.
0.1.0 (2017-03-03)
First release on PyPI.
Release files for vxci 0.0.60
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| vxci-0.0.60.tar.gz | 90.0 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| vxci-0.0.60-py2.py3-none-any.whl | Python 2, Python 3 | none | any | Details |
Total release size: 161.0 kB
Release files / vxci-0.0.60.tar.gz
| Download URL | vxci-0.0.60.tar.gz |
|---|---|
| Size | 90.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
aa95351ee259b0fbda62e4c0064f1042081663cecdb1367101bb69e456b3f1b2
|
|
BLAKE2b-256 checksum How to use checksums |
e98ac7bd580853b52d48b5b57272d4de7b0f4ec6a58641095bbbafcb7757123a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.10.16
|
Release files / vxci-0.0.60-py2.py3-none-any.whl
| Download URL | vxci-0.0.60-py2.py3-none-any.whl |
|---|---|
| Size | 71.0 kB |
| Tags | Python 2 Python 3 |
|
SHA-256 checksum How to use checksums |
83db052821dded44001fa74276f16b637c4be3eda0823ae0e7a4f69402e232c7
|
|
BLAKE2b-256 checksum How to use checksums |
8a238ac3c8f916b0ca04f339ad916ca85acc2c72ef41b36f7cb3e7dac90c8ff5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.10.16
|
Security for vxci 0.0.60
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
