Jenkins and Kubernetes/Spinnaker have very different data models
Build System | Entity relationships |
---|---|
Jenkins |
Org ← Repo ← Branch ← Build ← Test Report |
Spinnaker |
Org ← Repo ← Application ← Pipeline ← Run ← Stages ← Test Report |
† Branch is defined in webhook triggers for pipelines. DIfferent pipelines may be triggered by distinct branches.
A repository in a Github organization, e.g. MyOrg/MyRepo may have multiple applications.
Each pipeline may consist of multiple stages, e.g. (integration test → deploy → api test)
Multiple stages in the same pipeline may produce distinct junit/surefire xml reports.
In addition, unit test report data may exist from a build stage for a Docker image
Typical Spinnaker Test Data Lifecycle
-
Git: commit (with sha) →
-
Jenins: build → unit test → publish docker image →
-
Spinnaker/Kubernetes: pipeline run trigger → integration test → deploy → api test
Org ← Repo ← Branch ← Job ← Run ← Stage ← Test Suites |
Proposed Model | Jenkins | Kubernetes |
---|---|---|
Org |
Org |
Org* |
Repo |
Repo |
Repo* |
Branch |
Branch |
Branch* |
Sha |
$GIT_COMMIT |
Sha* |
Job |
jobInfo: { "host" : …} |
jobInfo : { "host" : …, "application": …., "pipeline": ….} |
Run |
Build |
Run |
Stage |
parameter |
String (e.g. unit) |
* Not native to Kubernetes model. Environment variable would need to be set as part of pipeline definition or defined when building docker image
A job entity solves several problems
-
Supporting multiple instances of Jenkins and/or Kubernetes
-
differentiating multiple runs for the same sha from different Jenkins or Kubernetes instances
-
Supporting application and pipeline as optional parameters to support indexable querying without needing any join tables
Entity | Fields | Candidate Keys |
---|---|---|
Org |
org_id : auto_number |
org_id |
Repo |
repo_id : auto_number |
repo_id |
Branch |
branch_id : auto_number |
branch_id |
Sha |
sha_id : auto_number |
sha_id |
Job |
job_id : auto_number |
job_id |
Run (Build) |
run_id : auto_number run_external_id : string context_fk : number |
run_id, context_fk and run_number |
Stage |
stage_id : auto_number |
stage_id |
Test Result ‡ (Test Suites) |
test_result_id : auto_number |
test_result_id |
Test Suite ‡ |
test_suite_id : auto_number package : string group : string
tests : number (aggregate) |
test_suite_id |
Test ‡ |
test_case_id : auto_number |
test_case_id |
Test Status |
test_status_id: auto_number |
test_status_id + test_status_name |
‡ _ See JUnit and Surefire XSD to show which fields are inherent to data model