Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI tests burning too much free consumption #32

Open
nathanjhood opened this issue Apr 17, 2023 · 1 comment
Open

CLI tests burning too much free consumption #32

nathanjhood opened this issue Apr 17, 2023 · 1 comment
Assignees

Comments

@nathanjhood
Copy link
Owner

Describe the bug
Keep running up to API hit rate limits due to exceeding test/cache run limits.

To Reproduce
Steps to reproduce the behavior:

  1. Make a branch to test on
  2. Push a simple (non-breaking, i.e., whitespace etc) change
  3. Check 'actions'
  4. Currently 24 actions running for multi-arch CMake tests alone!

Expected behavior
More efficient and practical testing workflows.

@nathanjhood
Copy link
Owner Author

Have been digging through the CMakePresets.json and CMakeSettings.json backend(s) to better understand - and support - cross-platform buildtools and runs.

For now, it's proven worthwhile to not narrow the functionality down to only a small subset of generators, compilers, workflows etc. Keeping the support as wide-open as possible (which is one thing CMake really excels at, it seems) has helped shine a few lights on the few tweaks necessary here which will be required() to continue establishing design patterns that allow for full use of CMake's strengths. Granted, confining ourselves to strictly needing to use Ninja-build, or configuring and building by useage of cmake-js' co-routines would probably secure more efficient advancements in the work being done on this project - in the short to mid term, but also quite neglects much of the usefulness of CMake itself. When other build tools are also available and more common to NodeJs, doggedly supporting CMake in favour would have to present it's full advantages in order to have been a worthwhile result.

For now, as of writing, we just need to merge in pending the latest successful tests - in which we discovered that, surprisingly, VS generators historically do not create a 'package_source' target for CPack, unlike all other generators. This is a bit of a sore point currently, as it has cost a lot of time, effort, and CLI runs to realize the mystery of a lack of functionality support that goes far beyond my control... but, it's hardly a show-stopping issue in itself, moving forward.

In the next round of submissions will be a bit (a lot) of exploration into json support with CMake - think execute_process(COMMAND node -p JSON.parse(${0})) - with the CMakePresets/Settings stuff, the cmake-js lib stuff, and some VS intellicode and template stuff. But it will be important to not fall into relying on these tools for the CLI runs, and maintaining that everything should successfully build and run as natively as possible, as it is now. Mostly these tools will be helpful at development-time, and also to help explore the possible configurations and required settings for cross-compilations - already underway on development branch :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant