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

Github Action Tax #194

Open
lmangani opened this issue Nov 16, 2024 · 2 comments
Open

Github Action Tax #194

lmangani opened this issue Nov 16, 2024 · 2 comments

Comments

@lmangani
Copy link
Contributor

lmangani commented Nov 16, 2024

The current extension template features a FANTASTIC Github Action set to validate our builds on all platforms and save us years in testing but there's a hidden surprise tax in Action costs. A little bit of extension hacking can easily consume 100% of PRO allowances within the first week of each month. The heavy hitters are windows and OSX builds which burn really fast 💸

As our extensions park grows this is becoming a pain and I would imagine this might eventually affect others too - finding out the hard way is very annoying and can literally halt one's development process for weeks (including other projects one might be using actions for). I'm opening this thread to try and find some ideas to lower the cost of development for community extensions.

Of course, rudely opening a garbage Draft PR to the community-extension repo and offloading to DuckDB Actions might be an option (I'm not sure who's credits it uses actually) but that's both feeling wrong and mostly unviable during early development phases and prototyping.

Other approaches could be defaulting a subset of the template actions to run on pushes and only running the full stack on releases, or perhaps implementing build caching between runs to slash the execution time. Is anyone experiencing the same?

Have a fantastic weekend!

@carlopi
Copy link
Collaborator

carlopi commented Nov 16, 2024

Thanks, that's valid a concern we have not addressed, and have not a clear plan yet.

I guess a testing mode with a single platform could be the default, and more expanded test to be done only on request (say via invoking the action explicitly or by opt-in)?

@lmangani
Copy link
Contributor Author

lmangani commented Nov 16, 2024

Another bummer with the current approach is it forces rebuilding all platforms when a single one fails (_WIN32 😆) and that's when I think cross-execution build caching might do miracles even with a short retention. Maybe ccache can be used with DuckDB builds?

image

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

No branches or pull requests

2 participants