CI/CD with Github Actions

[N-Storm]

This PR introduces automated builds using GitHub Actions (GA) runners, with support for uploading resulting binaries to the "Releases" section, along with release notes generation. The latter happens when a tag is created, but this can be adjusted to match a specific template or be triggered manually.

Supported configurations:

• Windows x64: CUDA 11.0 and higher
• Linux x86_64: CUDA 8.0 and higher

Building 32-bit binaries and supporting older CUDA versions within GA runners doesn’t seem reasonable to me. The time required to implement and test these would likely outweigh any demand. If possible at all—since, for example, Windows GA runners are only available in two flavors (MSVC 2019 & 2022). The currently supported versions should cover any hardware still useful for factoring.

Currently, I’ve enabled one target version per MAJOR.MINOR, selecting the latest .PATCHLEVEL available. In other words, for every X.Y.z, I pick one X.Y with the highest available .z. However, this can be easily configured in the .github/workflows/build.yml by uncommenting other versions. Or adding new if required. I’ve left comments there with the links to available versions.

It’s also possible to add a release flag so that generic builds run for every version listed, but only those marked with this flag get uploaded to the releases section. This is useful if you prefer not to upload too many releases but still want continuous builds to gather feedback on the build process as further changes are made. Builds that aren’t uploaded can still be downloaded by repository members with write permissions under Actions → [Build] → Artifacts, where they remain available for up to 90 days (configurable in the repository settings on the GitHub web interface).

I had to slightly modify Makefile.win to fix path and quoting issues for CUDA. Instead of using an intermediate CUDA_DIR, I switched to using CUDA_PATH directly. This should be safe for manual builds as well, but I haven’t tested it. If this change breaks manual builds or is otherwise unacceptable, it can be moved to a build helper script—modifying a local copy of Makefile.win during the build while keeping the repository version unchanged.

Example releases built using this workflow:

• 0.23.2pre4 Release link + Build Logs
• Recently added 0.24.0 test branch builds as well, if Makefile.win changes from this PR are merged into it:
  0.24.0pre2 Release link + Build Logs

Known Issue:

• Sometimes, Windows builds may fail early during the CUDA Toolkit installation step with an error message like this:

Warning: Failed to save: Cache service responded with 429 during upload chunk.
D:\a\_actions\Jimver\cuda-toolkit\v0.2.21\dist\index.js:6116
                       throw new Error(`Cache upload failed because file read failed with ${error.message}`);
                       ^

Error: Cache upload failed because file read failed with EBADF: bad file descriptor, read

This appears to happen because the GitHub cache service returns a 429 Too Many Requests status code error due to high load. In such cases, simply manually re-running all failed tasks from the web interface usually resolves the issue. At least that always worked for me on 2nd attempt.

Reducing the number of parallel jobs might help avoid this entirely if the rate limiting is based on GitHub account or repository. And assuming it's not a global denial happening for all users right now. Alternatively, the cache could be bypassed by downloading CUDA directly, or additional automation could be added to retry jobs that fail at this step. For now, we'll see how things develop; it may just be a temporary issue that gets fixed soon.

Feel free to PM me on the forums if you have any questions.

[brubsby]

First let me start by saying THANK YOU. Your work here is highly appreciated.

Building 32-bit binaries and supporting older CUDA versions within GA runners doesn’t seem reasonable to me. The time required to implement and test these would likely outweigh any demand. If possible at all—since, for example, Windows GA runners are only available in two flavors (MSVC 2019 & 2022). The currently supported versions should cover any hardware still useful for factoring.

Completely agree. We might have someone coming out of the woodwork to grumble about 32 bit versions, but they can implement it if they really want. The 64 bit versions are more than sufficient.

I'm also thinking we might want this PR to be the patch version bump to 0.23.2, if you wouldn't mind changing

#define MFAKTC_VERSION "0.23.1" /* DO NOT CHANGE! */

at params.h:89 to 0.23.2, then the release can be tagged and be the first automated one (which will also include the log corruption fix)

[N-Storm]

I'm also thinking we might want this PR to be the patch version bump to 0.23.2, if you wouldn't mind changing at params.h:89 to 0.23.2, then the release can be tagged and be the first automated one (which will also include the log corruption fix)

Thanks! I'll adjust it right now and update this PR soon.

[brubsby]

Also, fwiw, the changes to Makefile.win had no adverse effect on my personal build environment, so we're presumably good on that front as well.

[N-Storm]

Hmm... how do you think, maybe I should add my patch which replaces deprecated cudaThreadSetCacheConfig() and cudaThreadSynchronize() calls to the supported cudaDeviceSetCacheConfig() / cudaDeviceSynchronize() respectively to include it in the release?
I've posted about this on same forum thread recently. Changes made can be previewed in these commits: e737557, 7b536c6 (2nd are just a fix for a small error I've did, which only affects builds with DEBUG_GPU_MATH build option enabled)
It looks like 0.24.0 incorporates similar changes, nearly the same. I've tested those running a Windows for a few days without any issues now. Didn't noticed any difference with my compute 8.9 device, neither it helped to fix issues on RTX 5090. But doesn't hurts at least and might be of use with some other GPUs as well.

[N-Storm]

Added patch to replace deprecated API calls as well. Let me know if want it out of this PR / v0.23.2, I'll exclude it and force-push the branch without it.

PS: @brubsby, Your review was automatically dismissed when I've updated PR, so it has to be confirmed again if you accept it.

[KarlLudwig3485]

Seems to work fine on my setups.
I hope that any builds for CUDA <=11.x you make can run on Windows 7, as it seems a few people still use it on their systems. Otherwise I would be more than happy to continue providing builds for legacy/novelty systems (which I will continue to do for Windows XP and similar).

And I'm glad to report that your changes still work with CUDA 5.0 :)

[N-Storm]

@KarlLudwig3485 by CUDA <= 11.x & CUDA 5.0 do you mean Compute Capability devices actually? It it's like that, then yes, build with the CUDA version 11.0.1 targets devices with Compute Capability 3.5 - 8.0, so even 3.5 should be supported.
If you are talking about actual CUDA version, then I'm confused, because this PR explicitly notes that min CUDA version that can be used to build on Windows is CUDA 11.0.1 actually. Linux targets have much more options on supporting older CUDA versions, and currently it builds with CUDA as low as 8.0, which targets Compute Capability 2.0 - 6.2.
But this PR doesn't changes anything in the codebase. It only adds configuration and scripts for running automated builds via Github Actions feature.

[KarlLudwig3485]

My apologies, I didn't see that the Windows builds only went as far back as CUDA 11.0. And, given that Visual Studio 2022 still supports targeting Windows 7 by default (as far as I'm aware), it should work just fine.

As for CUDA 5.0, I was referring to the changes regarding cudaThreadSetCacheConfig() and cudaThreadSynchronize() being replaced with cudaDeviceSetCacheConfig() / cudaDeviceSynchronize(). Interestingly the former were already deprecated as early as CUDA 5.0 (I haven't checked any earlier versions yet).

[N-Storm]

@KarlLudwig3485 got it. Thanks for the feedback! Didn't thought at first that your comment was about that last addition, which I've included so recently. And it's so unrelated to the PR so I wasn't even thinking about it while reading your comment. :)
Yes, those call was declared deprecated pretty long time ago. But as NVidia explains on the deprecation notice: "Note that this function is deprecated because its name does not reflect its behavior. Its functionality is similar to the non-deprecated function cudaDeviceSynchronize(), which should be used instead.". So I guess those functions could be just a renamed or aliased. With the exception of cudaStreamSynchronize(), which work with the CUDA streams.

[tdulcet]

Just some comments in case they are helpful. Feel free to ignore.

[brubsby]

Added patch to replace deprecated API calls as well. Let me know if want it out of this PR / v0.23.2, I'll exclude it and force-push the branch without it.

Sorry for the slow response, since we're making the same change in 0.24, I would lean towards not including it in 0.23.2, just on the off chance that it causes issues with anybody on Linux (as seems to happen sometimes), and doesn't seem to fix anything if I'm understanding correctly. Especially as we're aiming to stabilize 0.23 and move on to developing 0.24.0.

However it does seem low risk, and already in the PR, so I'll defer to your judgement. Worst case we can do a 0.23.3 that removes it if issues crop up, and with the CI/CD now, that's not as annoying as it once was.

[brubsby]

Feel free to make any changes suggested by Teal, and I'll re-review, but I'm okay for this to go in as-is. Might also be easier to cherry pick onto 0.24.0 if this PR is squashed, but I'm okay with non-squashed if you want to preserve the commit history.

[N-Storm]

I was quite busy recently. Finally got time to return to this.
I've updated PR with a new commit. Removed deprecated CUDA calls patch and added most of the changes suggested by @tdulcet. I've squashed some of the latest commits into one, but keeping previous few commits with a history.

@brubsby, you can cherry-pick a range of commits in one run. See this link: https://stackoverflow.com/questions/9229301/git-cherry-pick-says-38c74d-is-a-merge-but-no-m-option-was-given

I'm waiting now for a build to complete on my fork to check for possible issues. Once it's all good and ready, I'll re-request review again and comment it here.

[N-Storm]

Currently Windows 2022 builds are broken due to Jimver/cuda-toolkit#382 / actions/runner-images#11691
Hopefully it will be resolved soon. If not, workaround is possible by manually unpacking & installing CUDA instead, but getting installer fixed would be preferred solution.

EDIT: Builds with Windows 2019 & MSVC 2019 still works. New Windows 2025 image has the same MSVC version, as 2022. So it's affected by the same issue as well. I have some progress installing CUDA manually, but I think we need to wait for a few days if normal installer will be fixed.
Alternatively I can submit version which builds with Win/MSVC 2019.

[N-Storm]

Confirmed to be a VS bug here: microsoft/STL#5282

[N-Storm]

It looks like a very easy workaround exists to install only some of the CUDA components. I've tested and looks like it's working, just need to add CUDA bin dir to PATH additionally (installing without broken "Visual Studio Integration" component which was used to set it). I'll test it a bit more and update PR if everything will be fine.

[N-Storm]

I guess it's all good now, build passes: https://github.com/N-Storm/mfaktc/actions/runs/13642472654

And I've added CUDA 8.x, 9x and 10.x Windows builds as well. I hope now it should be ready to merge.

[brubsby]

Looks good! Thanks again for putting all this together.