Added GitHub Actions workflows

Description:

• On each commit these workflows will be run to verify that project generation, source file compilation, and test cases run successfully.
• On each pull request a workflow will be run to verify that all fuzzing tests pass successfully.

Supports the following CI configurations:

• CMake
  • Ubuntu GCC
  • Ubuntu GCC OSB (out of source build)
  • Ubuntu Clang
  • Ubuntu Clang Debug
  • Windows MSVC Win32
  • Windows MSVC Win64
  • macOS Clang
  • macOS GCC
• Configure
  • Ubuntu GCC
  • Ubuntu GCC OSB (out of source build)
  • macOS GCC
• Fuzz
  • OSS-Fuzz on pull request only

Example runs can be found here: https://github.com/nmoinvaz/zlib/actions

This PR does not change any source code and only adds yaml workflows. Take from this PR what you need.

@madler consider getting rid of appveyor and use GitHub Actions.

@madler: What do you think?

I did some minor cleanup incase anybody cares.

FWIW, I support this. :) The changes from https://github.com/madler/zlib/pull/492/files test/example.c would still be helpful.

Back when that other pull request was proposed, there was concern within Google about Github Actions not being secure enough. That has since changed. And given the change, I recommend using Github Actions instead of AppVeyor.

It will be much easier for everyone involved, too. You'll recall last time we tried to get AppVeyor running it had more steps (each of which required confirming it is safe) than it was worth. With this, we won't need those annoying steps.

It might be good to land this first. Then I can update the other pull request to not include any AppVeyor parts. That'll bring the useful test/example.c changes in.

So I just add these files, and then, magic? Are there any settings or permissions on GitHub needed?

I think I have turned off appveyor.

Correct, magic, if you build it they will come.

By the way, something I did not add was the ability to check to see that contribs compiled. Perhaps contrib authors can add those workflows. And I did not add checks for the vcproj files you have. Only checked cmake and configure.

If there is interest I can look into some of that.

Pull requests need to be on develop, not master. @nmoinvaz Can you resubmit?

They should be activated for all branches. Are you saying you only want for develop?

Yes, develop. master is only for releases. When there is a new release, the files will end up on master as well.

You should be able to press the Edit button on this PR on the top right and change it from master to develop.

Didn't know I could do that. Thanks!

I'll submit a pull request to get rid of AppVeyor. That "build failed" just then is annoying. :)

Oh. The AppVeyor files didn't land. I think the error is because the AppVeyor account is linked here but isn't finding any files instructing it.

You can probably log into AppVeyor and remove zlib from the repos for it to check.

@ProgramMax I have deleted zlib from appveyor. Hopefully it has been exorcised now.

Sounds good. It is likely still showing up here because there have been no code changes and GitHub remembers the last CI results. But future changes should be fine.

Please don't force push into pull requests when it isn't necessary for the future. Reviewers have to start again to review the entire pull request instead of just the new changes. Additionally, you don't give any credits to the reviewers for code suggestions.

Please don't force push into pull requests when it isn't necessary for the future. Reviewers have to start again to review the entire pull request instead of just the new changes.

There are pros and cons of each way.

Additionally, you don't give any credits to the reviewers for code suggestions.

I'm not sure that it makes sense for EVERY suggestion to be credited. The commits in zlib are always authored by @madler and he can credit whoever he wants - even all 6 participants on this PR. After having it open for 2 years I would be happy if the changes are merged even if I don't get credit. A lot of the changes I made since last push were already made by me in zlib-ng GHA workflows (which is where these workflows come from) but this PR was never updated, your suggestions I have already made there even, although the GCC issue was only partially made in zlib-ng already.

Rebased.

Incorporated.

Thank you so much @nmoinvaz for this! It seems to working great.

I say "seems", only because it's always giving a green check mark. I find this suspicious. I went in and looked at the output, and I didn't even see any warnings. Will this show or flag warnings from the compilations? Or only errors?

Agreed. Thank you for doing this, @nmoinvaz.

Warnings are allowed by default. Errors will not give a green check mark. We can add a flag to treat warnings as errors if we wanted. Any step that has a non-zero exit code (IE returning -1 from main()) will prevent the green checkmark.

It does seem strangely quiet, though. Things which I thought would return non-zero aren't.

There are 3 jobs: Ubuntu GCC, Ubuntu GCC ISB, and macOS GCC. Only the Ubuntu GCC ISB is really working. The other two print "Please use ./configure first. Thank you." and "make: Nothing to be done for 'test'.".

So I think we have some follow-up work to do. But it is correctly building and testing on Ubuntu GCC ISB.

Oops. Let me correct myself: There are 3 workflows. The "Configure" workflow behaves the way I described above. There is also a "CMake" workflow that builds and tests correctly on all of its platforms. Then there is an "OSS-Fuzz" workflow which hasn't run yet.

What is "GCC ISB"?

ISB = In-Source Build.

For CMake, it is common to: $ mkdir build $ cd build $ cmake .. Then all build files are inside the build/ subdirectory, rather than scattered within the code. The non-ISB jobs do this. The ISB job does not.

@ProgramMax is right.

And configure working-directory steps should be changed to:

When I created this PR 2 years ago, there were some CI instances I knew weren't working, but I decided to only go with those that were working first (I don't remember which ones failed). It also may have been something incompatible with zlib CMake/configure itself.

I can add more CI instances to the workflows (ARM, etc) in another PR.

Also we don't check building of any contribs.

Also we don't check building of any contribs.

That's fine for now. The only one we might eventually want to add is minizip. I check that one in my internal tests.