getting development versions of ADMB from GitHub Actions?

[iantaylor-NOAA]

In the discussion about a proposed revision to the admb console output (#219), @Cole-Monnahan-NOAA asked "Would you be willing to test the fork on your own models before I do a PR?". A separate email discussion today with @Rick-Methot-NOAA, @kellijohnson-NOAA, and @k-doering-NOAA about the hess_step option (which I think made it into ADMB 12.3, but maybe not the most recent refinement) has me wondering about getting compiled development versions of ADMB from the github actions.

I just confirmed that I can download the "artifact" at the bottom of the page for a github action, unzip the file, and click on the "ADMB Command Prompt" shortcut and successfully use ADMB as represented on the branch in question (in this case it was the issue-223 which happens to be the most recent.

However, the changes that @Cole-Monnahan-NOAA has contributed are in a fork and it appears that they all fail with this message: "This request was automatically failed because there were no enabled runners online to process the request for more than 1 days." (see https://github.com/Cole-Monnahan-NOAA/admb/actions/). Once a Pull Request is created, the "CodeQL" action is triggered, but the actions that compile the software are not.

I know that we could all just compile ADMB locally, but downloading it already compiled would definitely make it easier to test things.

First, thanks @johnoel for setting up the GitHub Actions in the first place. I think all the automatic checks associated with compiling on these platforms are really valuable and the transparency of having it all up there on github is great.

My questions are,

1. Does it make sense to use artifacts from GitHub Actions as a way for users to provide feedback on in-development changes to ADMB?
2. Is there a way to do this for a fork or pull request?
3. Which of the Windows versions (msys, rtools, vs2019, etc.) becomes the release and does it matter which one we use for testing things (rtools40-64bit worked fine for me, but I have rtools40 installed and I don't know if that is needed).

[Cole-Monnahan-NOAA]

I'll let @johnoel answer the big question. Note that my fork is totally broken wrt RE and autodiff models but should work for SS. We're working on resolving it. If you want to test please revert back to an earlier commit. Sorry about that.

[Cole-Monnahan-NOAA]

For what it's worth, as a developer on Windows my workflow is to clone/pull whatever repo/branch you need. Then go to the ADMB 12.3 command prompt, migrate to the "admb" repo. Then just do make -j4 will build the whole thing from scratch. Then the admb.cmd in that folder can be used to compile templates with that specific version.

[k-doering-NOAA]

For 2., I think the issue on Cole's fork is that the runs-on: includes self-hosted. I think the person would have to either set up their own self-hosted runner or change the github actions to only use the github hosted runners.

However, I think when a pull request is made to admb, the jobs could run on the self-hosted runner.

[johnoel]

For 1 and 2, GitHub Actions can be configured to run pull requests which will produce the artifacts. It's a nice feature and I have sent the artifact links to users for testing bug fixes. I will configure it later today to work with pull requests.

For 3, the single admb windows installer has support for multiple compilers such as Visual Studio, rtools (versions 4 and 3) and msys2. For local machines without a compiler installed, Mingw-w64 compiler from Msys2 is included with the admb installer.

[iantaylor-NOAA]

Thanks @johnoel. This all sounds good. I didn't realize how sophisticated the installer was. Thanks for setting it up that way.