0.10.1

Security fix

• Fix /builds endpoint making it possible to access arbitrary .json and .xml files on the host system.

Features

• TeamCity build chains are synced for automatically triggered downstream jobs (#24).

0.10.0

Breaking changes

• A class name for test results is now required for the JSON schema, aligning with JUnit XML (#21).

Bug fixes

• Tooltips in "failure phases" graph are now shown in Chrome (#16).
• Test runtime is now optional for the JSON schema, aligning with JUnit XML (#20).

Features

• Support for TeamCity.

0.9.0

Breaking changes

• Schema: source_id has already been replaced with sourceId, but has now been made invalid. The newly introduced triggeredBy now requires a list of entries, instead of a single one.

Bug fixes

• Jenkins builds can be triggered by multiple others. These occurrences are now correctly reflected in the pipeline graph (#19).

Features

• New graph "Wait times" to surface bottlenecks in the pipeline.
• Graph descriptions link to a wiki for more background information.

Improvements

• On server startup the available options and current settings are displayed.
• Timestamps for build start and end must now have at least 13 digits. This is to guide users when setting up buildviz integration, and to avoid the issue of incorrectly providing values in seconds.
• Job names are now wrapped along hyphens and underscore to support long build names in TeamCity.

0.8.0

Breaking changes

• All JSON keys are now camel-cased, one offending key has been renamed to sourceId.
• /pipelineruntime API has been renamed to /jobruntime to make place for the new pipeline runtime feature.

Bug fixes

• Syncing a partially re-run stage from Go.cd resulted in the stage being incorrectly reported as passed (#17).

Features

• Pipeline runtime graph shows the average feedback time for all chains of jobs. This requires new field triggeredBy in build data.
• Sync build script for Jenkins CI.
• Test results can now be uploaded in a simple JSON format.

Improvements

• Flaky job ratio is now calculated relatively to failure rate instead of total build count.
• Description for graphs and various other usability improvements.

0.7.0

Breaking changes

• /failures API has been removed, its functionality has been merged into /testcases (retaining the existing structure).

Bug fixes

• Flaky build and Flaky tests graphs now correctly show flaky entries. In the past the graphs also included consistently failing entries, if inputs partially matched.
• Most frequently failing tests graph now handles tests with duplicate names correctly. Two tests with the same name failing in the same run are not counted twice, which previously would've given the wrong impression of one test failing twice, rather than two tests once each.
• For JUnit XML without classnames results in CSV are now correctly returned.

Improvements

• Flaky tests will now even be recognised in subsequent failing builds (given different test outcome). Previously, one build had to pass for tests to be considered. This will also enable the graph to show data with the need of build outcomes specified. (#13)

0.6.0

Breaking changes

• The start of a build is now mandatory. As data grows, we inevitably want to select the newest builds only, therefore requiring a timestamp.

Features

• All graphs will expose the questions they are trying to answer.
• The timespan of a graph can be selected, overriding the default interval.
• The pipeline name can be configured using the environment variable BUILDVIZ_PIPELINE_NAME.

Improvements

• Failed and flaky builds will indicate the job's colour.
• Loading indicator.
• Indicate the data necessary for each graph to render.
• Initial help is shown for a new instance.

0.5.0

Breaking changes

• Build and test data is now stored in single files, one per build and job unter data/

Features

• The data directory can now be configured via environment variable BUILDVIZ_DATA_DIR
• New graphs: flaky tests and slowest tests

Improvements

• Only the 5 most flaky or failing tests are shown to contain the noise, as failures are a nature of build pipelines, and only excessive failures are a systematic issue
• 'Redness' is now based on absolute (and opinionated) values, as the absolute failures are relevant, rather than relative to other jobs
• The same job in different graphs now will be shown in the same color, hover on the job will highlight same job in other graphs
• Graphs showing averaged data now limit the result set to the past one or two weeks to limit the influence of historical data

0.4.0

Breaking changes

• Go.cd sync
  • The command was renamed to buildviz.go.sync.
  • By default the command will now create jobs in buildviz for a whole stage run. All jobs of a stage will be aggregated, including XML test results. To yield the previous behaviour where a job in buildviz matches a job in Go.cd, specify --sync-jobs PIPELINE for every pipeline in question.
  • Pipeline groups selected for syncing now need to be passed via a command switch instead of as arguments: --pipeline-group GROUP.
  • Job names will be shortened if the Go.cd job name matches the stage name.
  • By default the script will now pick up where it left off when starting a new sync, and when interrupted can now just be re-run without having to start from the original given date.

Other changes

• New graph for job runtime over time.
• Multiple occurrences of the same test will now be aggregated instead of averaged over (#5).

0.3.0

• Go.cd sync functionality is now included in the standalone jar.
  • Fix issues with faulty Go.cd responses.
  • Support Go.cd installations not hosted under /go (#11).
• Provide a nicer UI with zoom funcionality.
• Fix issue with ordering of source inputs (#8).
• Improve UI of fail phases graph, indicate weekends, provide more information on hover.
• Group classes by package for test case runtime graph (#10).
  • Improve display of one-child suites.

0.2.0

• New graphs:
  • Test suites by runtime
  • Pipeline failure phases
• CSV export
• Go.cd import script improvements:
  • Better error handling
  • Import until given date to import older builds as well
• Input validation: Fail on invalid JSON / JUnit XML
• Build data persistance
• Initial support for flaky test cases and job runtime by day
• ... and more