Versions Compared

Old Version 1

changes.mady.by.user Brian Harrington

Saved on

compared with

New Version Current

changes.mady.by.user Edwin Lu

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated summary and process since the process is a bit different compared to gcc pre-commit

...

This project is intended to help answer the question of whether a patch meets some of the minimum requirements to be merged into GLIBC, as an aid to maintainers and developers. We also run postcommit CI runs to monitor the health of trunk and assist in triaging unintended breakages.

Process

The GLIBC CI is a 2 part system.

...

 

Process

When a new patch with "RISC-V" in the title is submitted to the mailing list, the precommit pulls it from <TBD> patchwork. A variety of checks (does the patch apply, linting, build, test) are then run using the post-commit CI as a baseline and source-of-truth for expected failures.
The build/test logic is as follows:

if patch_applies_to_baseline:
    perform build+test, comparing testsuite results with the baseline testsuite results
if patch_does_not_apply_to_baseline and patch_applies_to_trunk:
    perform build
if patch_does_not_apply_to_baseline_or_trunk:
    report a warning

...

. If the patch applies, the CI will start two runs: one using the current tip of tree and the other using the tip of tree+applied patch. Once the two runs have completed, the testsuite results are diffed and reported.


Results are reported to patchwork and may be manually interpreted/directly emailed to upstream maintainers.

Postcommit CI

An example output from postcommit ci:
<TBD>
Dashboards:
<TBD>Precommit CI


An example output from precommit ci:

...