Switching MetaMorpheus and mzLib from AppVeyor/Jenkins to GitHub Actions?

[acesnik]

I've recently switched Spritz and TopDownSDK over from using AppVeyor to using GitHub Actions for continuous builds and periodic testing, and I'm finding it to be pretty great in comparison.

Here are Spritz's build and release scripts (more like MM with uploading to a GitHub release), and here are topdownsdk build and release scripts (more like mzLib with a nuget push).

Is there any interest in switching MM and mzLib over to GitHub Actions? One advantage of switching mzLib and MetaMorpheus over to GitHub Actions would be that the scripts for these builds would be contained in the repositories themselves, rather than on AppVeyor and Jenkins on separate services or machines. They can then also be updated with pull requests if needed based on the changes (e.g. https://github.com/smith-chem-wisc/MetaMorpheus/pull/2060). The builds seem to be a bit quicker than AppVeyor, too.

The checks/builds can then be viewed on the main page by pressing the green check or red X on the latest-commit line of GitHub, and they can be used as gates for PRs in the same way as AppVeyor. Here's that view within Spritz, for example:

[acesnik]

Here's a draft of the actions that AppVeyor is doing: https://github.com/smith-chem-wisc/MetaMorpheus/pull/2128/files.

[trishorts]

that's pretty cool. it kinda does a jenkins sort of thing.

[acesnik]

Yep! And it'll be version controlled and all in one place.

[rmillikin]

just fyi i tried to use github actions, and abandoned it because it did not share secrets across forks. so if you've forked MM, and you have an API token saved as a secret on the upstream repo, your fork will not be able to access that API token secret. this is deliberate, for security reasons (you could fork someone's repo and print out their secrets, for example). I went back to appveyor because it's self-contained and no one is able to access secrets stored on appveyor via forking.

[acesnik]

These are great notes. What issues did you run into with token usage on other forks? Personally, I find these to be more features than bugs:

• The release workflows require tokens to place the installer and commandline zip file into a Github release, and this is only useful for the main fork where the release is located.
• AppVeyor used codecov tokens, but these are not required for open source projects
• Tokens for deploying docker images and nuget packages should be located only on the main fork, where the packages and images are released from and tagged
• Pull requests to the main branch can activate token usage on the main branch if needed

[rmillikin]

I forget the specifics but I think it was about deploying a docker image. IIRC I tried to deploy a docker image to dockerhub on PR merge or something like that, with my docker username and password as secrets. but github actions wouldn't deploy it because it didn't have access to my secrets

[acesnik]

I’ve had success automatically deploying Docker images to Docker Hub from Github Actions for Spritz using tokens created under Settings -> Access Tokens in Docker Hub. I wonder why you had issues with accessing the secrets!

[rmillikin]

I sort of remember it better now...

1. make PR to upstream from my fork
2. something went wrong in the GH actions script that I wanted to fix
3. Fix the script
4. could not get my PR to run the updated script instead of the original script
5. create a .sh script that basically just does what appveyor does, use GH actions to just download and run the .sh script
6. could not access secrets in the .sh script to deploy to docker hub
7. get annoyed with GH actions and quit

[rmillikin]

so basically my hacky workaround didn't work because of security reasons (probably a good thing). if you can get GH actions to run an updated GH actions script with an open pull request then you're smarter than me