Tiki releases every 6 months. However, the next release should ideally be "releasable at any time". So we:
- We use use Continuous Integration http://en.wikipedia.org/wiki/Continuous_integration, in our case using GitLab CI
- Also, the actual process of Releasing should be very easy (goal: 30 minutes for the technical part).
Most of the tests are now done via Gitlab CI , which is run on every commit.
See the pipeline status at https://gitlab.com/tikiwiki/tiki/pipelines
The CI runs on every commit. This can take 10 minutes, so you want to run the main tests locally before you commit so you don't constantly break the build, and have to rework your merge request. See TikiDevNewbie
Why would you want to?
- To fix a pipeline failure when the code is correct
- To make the pipeline run faster/be less costly to run (external service quota, etc.)
- To make parts of the pipeline easier for other developers to work with, or to adapt the pipeline to changes in the underlying tiki tools and scripts.
Traditionally, gitlab-ci.yml files are meant to be edited with the gitlab's pipeline editor. While a very nice tool to test and validate some aspects of the logic of that file, iterating on the pipeline and running the actual tests requires a commit. Even on a branch or clone, it is extremely time consuming.
So to work on it your should learn to:
gitlab-ci-local, which allows you to run a specific job locally, mostly as it would on gitlab.
The gitlab-ci.yml file should only be concerned with setting up reproducible test environments, not setup tests that depend on one-another, etc. So the actual tests should be in separate scripts called from gitlab-ci.yml. Also, while a developer should not be expected to have every possible dependency installed, the tests should run in their local environment if they are working on this part of the code. For example, manticore tests should be runnable from however manticore is locally installed, not just from docker.
To get closer to these goals, the ideal would be community Continuous Integration server.
There are daily builds but if something breaks, there is no alert system to report the issue.
For humans to be able to see yesterday's data with tomorrow's code
- Having a test server with main profiles applied regularly, for testing/demo.
For the daily pre-release zip file to be as close as possible to the final one
- Run the existing scripts we use at release time
- Automatic commits: we could register a "tikiwiki" user at Sourceforge.
- Permission deniedYou are not allowed to view this item.
- update of changelog.txt (maybe once a week?)
Machines testing code, according to a series of tests
- Run all tests
- Run the security tests regularly (monthly?) and report to Security Team about new potentially risky files
- Ideas from How to improve the release process
- php doc/devtools/translate.php englishupdate
lag=10audit --firstname.lastname@example.org to report if anyone breaks strings over the last 10 days
In order to run the script
doc/devtools/check_schema_upgrade.php which will compare your current database with what it should be you need to install DBDiff with this command:
. php temp/composer.phar require "dbdiff/dbdiff:@dev"
- PHPCI is a free and open source continuous integration tool specifically designed for PHP.