High Level Goals
| Goal |
Motivation |
| Dev Velocity |
Improve development velocity of DrupalCI itself
Functional end-to-end black-box tests.
Unit tests validating specific functionality
Adhere to coding standards for comprehensibility
Enforce good patterns in codebase organization
|
| Codebase |
Enhance Codebase construction
Dependency calculation is the largest source of issues, and cannot be changed in a patch.
- Developers need a way to specify which dependencies they want (prefer stable vs prefer dev), which branch of core
- Improve the output for Devs so they can see what actually changed/was built.
- Better handle errors during codebase builds.
|
| Environments |
Support Dynamic Environments
- Deployment free environment adjustments need to be possible to accommodate the diverse demands of the developers, allowing for custom configuration settings, and new environment types. Developers and testbot administrators need to fully decouple environment definition from the drupalci codebase. Environments need to be defined externally, in configuration, and not in code.
- There are two elements to be accommodated:
- Containers
- Configuration within containers
|
| Tasks |
Support for multiple Job types
- There is high demand for additional job types, so we need to be able to run multiple jobs in a build, and make it easier to implement new jobs without smearing classes all over the filesystem
|
| Output |
Improved information and results for end users
- Properly structure and unify output and build artifacts across the application
- Console output is unstructured and inconsistent
- Errors are hacked in (patch application)
- Solidify and unify output for Jenkins, the main consumer
- Many build artifacts are missing that could help end users diagnose problems.
|
| Admin |
Enhanced project and testing configuration on drupal.org
- Give developers ability to control drupalci from their projects.
|
| Docs |
Improve documentation of everything because it’s good, and holy.
- Reporting issues
- Utilizing local testing
- Contributing guidelines
- DrupalCI Docs in general migrated to new documentation section.
|
| Cost |
Look at our cost controls throughout the process of making these changes
- We need to be careful with changes that create significant increases in test setup time.
- We may need to find ways to better meter our testing resources.
|
Roadmap
| Epic |
Goals Supported |
Functional Tests for existing DrupalCI |
Dev Velocity
|
Re-architecture of Codebase to support Builds, Stages, and Tasks. |
De Velocity, Codebase, Environment, Output, Tasks
|
| - Standardized output for Build/Stage/tasks for output/errors/artifacts/status |
Output
|
Can have multiple types of testing tasks per build |
Tasks
|
DrupalCI runs on PHP7 |
Dev Velocity
|
Builds utilize Composer |
Codebase
|
| Patch Application Enhancements |
Codebase
|
| Code Linting implemented as Codebase Stage Tasks |
Codebase
|
| Containers are based off of official Containers, with additional php/mysql/pgsql containers. |
Environments
|
| Simpletest Task Behavior enhancement |
Tasks
|
| Make the tests faster & provide testing speed metrics |
Cost
|
Support for Codesniffer Task |
Tasks
|
| Support for PHPUnit Task |
Tasks
|
| Output is available on Drupal.org via jenkins API. |
Output
|
| Injectable configuration |
Environments
|
| Dynamic Ad-Hoc Enviroment Construction with docker compose. |
Environments
|
| Ability to submit an arbitrary environment for testing through D.O |
Environments
|
| DrupalCI enforces job target policy |
Admin
|
| DrupalCI enforces environment target policy |
Admin
|
| DrupalCI enforces code target policy |
Admin
|
| All trigger points required are built |
Admin
|
| Give developers ability to configure the ^^ targets for their project per trigger point. |
Admin
|
| Support for Code Coverage Task |
Tasks
|
| Support for BDD Task |
Tasks
|
| Jenkins job weight plugin to fill underutlized nodes with tests. |
Cost
|
| Job pipelining : Sub-segment jobs to run the fastest tests first. Bail early on failures. |
Cost
|
Comments
Comment #2
hestenetComment #3
hestenetComment #4
hestenetComment #5
daffie commentedCan #2810049: Support PostgreSQL variable bytea_output with value "hex". be added on this roadmap?
Comment #6
Mixologic@daffie: that would already be covered under the environment work:
Injectable configuration Environments
Dynamic Ad-Hoc Enviroment Construction with docker compose. Environments
Ability to submit an arbitrary environment for testing through D.O Environments
Comment #7
andypostphp 7.1 released any plans to add it?
Comment #8
MixologicYep, thats covered by the 'Support Dynamic Environments' plan.
In the meantime we'll probably do a special case for 7.1 depending on what the core devs want. Its been on a daily snapshot of 7.0 for a long time, and probably should not be.
Comment #9
damienmckennaCould this please be cross-linked with the relevant issues?
Comment #10
Mixologic