Add Cirrus CI; add --force_fail and --fail_fast options to example.c#495
Add Cirrus CI; add --force_fail and --fail_fast options to example.c#495dankegel wants to merge 21 commits intomadler:developfrom
Conversation
To make it easier to accept contributions to zlib we should establish automated testing. This commit uses the existing test/example.c testing. It connects those tests to AppVeyor, allowing AppVeyor to mark commits as passing or failing the tests. It also automatically runs tests when a pull request is submitted or updated. There is some room for future expansion enabled, such as tracking the file and line of a failing test. This is thanks to @dankegel, who also got this working on CI providers other than AppVeyor.
… additional options
|
If you want to merge the two pull requests, you can save your changes off to the side and delete your fork of madler/zlib. Then fork my zlib, fetch it, reapply your changes, upload, and submit a pull request to my fork. Once included in my fork it becomes included in my pull request. |
|
You'll probably want to add badges to the README.md to indicate which builds are passing / failing. |
… on, otherwise no change.
…rus/github Also don't output file or line on success, since annotating those on github just adds clutter.
CMakeLists.txt: output junit result file for each test executable to ${CMAKE_CURRENT_BINARY_DIRECTORY}.
(Would have liked to output them to the $<CONFIG> subdir on Windows
for multi-config generators like Visual Studio, but
alas, I couldn't coax cmake's generator expressions
into working portably without complicating CMakeLists.txt
beyond reason. Happily, it's uncommon to run both
Release and Debug build and test in same tree on CI builders.)
|
OK, badge added. (Annoyingly, looks like Chrome caches badges aggressively.) I hesitate to delete my repo... that's given me trouble in the past. Could you consider the following commands instead? ? |
|
Or you could just land yours and I could rebase this one afterwards. |
|
That option works for me. :) |
|
@dankegel, there is a simpler way to do this. You can just add @ProgramMax's fork as a remote on your local zlib repo: Create a branch based on the branch he used to open his PR ( (here the local branch will be called (assuming you have your own zlib fork on GitHub as the And then open a PR from your |
|
Well, yes, that is what I tried to do. I rebase onto his branch whenever he updates it. Evidently this is a known issue with github: The suggested workaround is to construct a URL like https://github.com/DanKegel/zlib/pull/new/ProgramMax:develop...DanKegel:develop Closing in favor of ProgramMax#2 for now. |
I wanted to make this a pull request against https://github.com/ProgramMax/zlib/tree/develop
but Github won't let me, so here it is against madler's develop branch.
It's just Chris's branch plus --force_fail and --fail_fast options to example.c that I found useful,
as well as cirrus-ci builds on BSD, mac, linux, and windows.
The README now shows status badges for both Appveyor and Cirrus; see https://github.com/dankegel/zlib/tree/develop for what it looks like when the git repo has those two services enabled.
When cirrus-ci builds fail, Github displays test failures with links to source lines,
see example at https://github.com/dankegel/zlib/pull/3/checks?check_run_id=690339991
Perhaps more usefully, in pull requests they also show up in the 'Files changed' tab, see example at https://github.com/dankegel/zlib/pull/3/files (and scroll down to the 'Unchanged files with check annotations' section!).
(This pull request used to also add Linux builds via travis-ci.org and drone.io for Power, S390x, and Arm, but I've banished those to https://github.com/dankegel/zlib/commits/moreci for now.)