Add GitHub Actions for Releases and a Docker container

[wfondrie]

This PR refactors our previous GitHub Actions workflows to automatically upload build artifacts to releases created within GitHub. Here's how it should work:

When a commit is pushed to master or a pull-request is made with master as the target of the merge:

1. Comet will be compiled on Ubuntu, MacOS, and Windows.
2. We check that the new Comet executable can create a new param file. (Here is an excellent place for other tests if we have them)
3. If any build / test fails, we should see an ❌ notifying us. If it's a pull-request we should probably fix the problem before merging it into master 😉.
4. For the Linux build, we create a Docker container and verify that the Docker container works (per Docker container with releases #5).

When a new release is created using the "Releases" tab in GitHub:

1. Comet will be compiled on Ubuntu, MacOS, and Windows.
2. We check that the new Comet executable can create a new param file. Hopefully neither of these steps fail, because they should have completed successfully when the most recent commit was added to master.
3. Each build will upload it's build artifacts to the Release page. Currently, I've configured these to be a compressed archive containing the executable and README.md for each platform. After all have completed you should see linux.tar.gz, macos.zip, and windows.zip available for download under the Releases tab.
4. For the LInux build, we create a Docker container. This is uploaded to the GitHub Container Registry where folks can use Docker to grab it.

I'd advise on waiting to merge this PR until we have the Windows build up and running.

Any other feature requests, questions, or comments?

[jke000]

Here's a couple of basic questions. I have been adding release notes with each release. I'm just trying to understand where the release notes should exist as the root README.md doesn't seem to be the right place for the release notes. Presumably add some file like RELEASENOTES.txt to the repo and copy that to each release archive? I have a set of tests I've been running before each release. It's currently a manual process to edit each of the parameters for the various tests for each new release as I'm effectively running a bunch of searches and validating the results. What's the proper way to adding such tests and I guess specifically any advice on how I should deal with the spectra and sequences? Encode those within the program itself (not too horrible for the small tests) or can the data be external from the binary itself?

…

On Fri, Nov 12, 2021 at 4:48 PM Will Fondrie ***@***.***> wrote: This PR refactors our previous GitHub Actions workflows to automatically upload build artifacts to releases created within GitHub. Here's how it should work: When a commit is pushed to master or a pull-request is made with master as the target of the merge: 1. Comet will be compiled on Ubuntu, MacOS, and Windows. 2. We check that the new Comet executable can create a new param file. *(Here is an excellent place for other tests if we have them)* 3. If any build / test fails, we should see an ❌ notifying us. If it's a pull-request we should probably fix the problem before merging it into master 😉. 4. For the Linux build, we create a Docker container and verify that the Docker container works. When a new release is created using the "Releases" tab in GitHub: 1. Comet will be compiled on Ubuntu, MacOS, and Windows. 2. We check that the new Comet executable can create a new param file. *Hopefully neither of these steps fail, because they should have completed successfully when the most recent commit was added to master.* 3. Each build will upload it's build artifacts to the Release page. Currently, I've configured these to be a compressed archive containing the executable and README.md for each platform. After all have completed you should see linux.tar.gz, macos.zip, and windows.zip available for download under the Releases tab. 4. For the LInux build, we create a Docker container. This is uploaded to the GitHub Container Registry <https://github.blog/2020-09-01-introducing-github-container-registry/> where folks can use Docker to grab it. I'd advise on waiting to merge this PR until we have the Windows build up and running. Any other feature requests, questions, or comments? ------------------------------ You can view, comment on, or merge this pull request online at: #6 Commit Summary - d09ee96 <d09ee96> Add releases and Docker container File Changes (5 files <https://github.com/UWPR/Comet/pull/6/files>) - *D* .github/workflows/build.yml <https://github.com/UWPR/Comet/pull/6/files#diff-5c3fa597431eda03ac3339ae6bf7f05e1a50d6fc7333679ec38e21b337cb6721> (31) - *A* .github/workflows/linux-build.yml <https://github.com/UWPR/Comet/pull/6/files#diff-f7f5582d7c4b2247b94182251a37bbbe432dbf3d552ab7a17841c68e29a348d6> (63) - *A* .github/workflows/macos-build.yml <https://github.com/UWPR/Comet/pull/6/files#diff-3569b5feda562f1b9cb8c965c02dc80df7a1969e39e0a8ecb0439553a248222a> (33) - *A* .github/workflows/windows-build.yml <https://github.com/UWPR/Comet/pull/6/files#diff-006d566e109ce80a80cbd243c89a25b876792c89e18c2fb931eaba8535e4ed00> (39) - *A* Dockerfile <https://github.com/UWPR/Comet/pull/6/files#diff-dd2c0eb6ea5cfc6c4bd4eac30934e2d5746747af48fef6da689e85b752f39557> (11) Patch Links: - https://github.com/UWPR/Comet/pull/6.patch - https://github.com/UWPR/Comet/pull/6.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACIDBUPSP7M47CUA337573TULWYXTANCNFSM5H57M3TQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[wfondrie]

Presumably add some file like RELEASENOTES.txt to the repo and copy that to each release archive?

This seems like a good idea to me. In my Python projects I use a file called CHANGELOG.md that contains the release history in the format suggested by https://keepachangelog.com/en/1.0.0/.

Regardless, we can put any files you want into the release archives.

What's the proper way to adding such tests and I guess specifically any advice on how I should deal with the spectra and sequences? Encode those within the program itself (not too horrible for the small tests) or can the data be external from the binary itself?

I'm certainly not an expert on testing C++ programs, but I know that the crux folks use Cucumber to run such tests (in crux they call these "smoke tests", but I think a lot of folks would call them "system tests". Alternatively I use pytest to run unit and system tests on all of my Python packages. If we just want to run Comet with different sets of parameters and compare the outputs, I could do this fairly easily with some Python code. Lastly, if we ever want to write unit tests (testing specific functionality within the code base), then GoogleTest is probably the most popular option (and the Percolator folks have started using it too).

As for where the tests go, they certainly do not have to be included with the executable. I think we would want to create a top level tests directory where the testing code, spectra, and sequences could reside. Additionally, if the spectra and/or sequences are too large to reasonably store in version control, we could also download them from somewhere before the tests are run.

In the case of crux, I know they keep small spectra and sequence files in the GitHub repo for testing.

[mammmals]

Looks good overall with the windows build holding us up for now.

[mammmals]

Approving to move forward