This happens when there’s too much logic in the build server.
I hate GitHub Actions with passion
201–210 of 347 posts
Re: I hate GitHub Actions with passion
#202Earlier quoted context omitted.
> It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI). UV scripts are great for this type of workflow There are even scripts which will install uv in the same file effectively making it just equivalent to ./run-file.py and it would handle all the dependency management the python version management and e…
> UV scripts are great for this type of workflow So previously when I have seen Python used as a task runner I think they used UV to call it. Although I don't think they had as a complete solution as your here auto-installing UV etc. Although the example you've linked is installing UV if missing, the version is not pinned, I also don't think it is handling missing Python which is not pinned even if installed locally.…
I think UV scripts can/will actually install python and manage it itself as well and you can actually pin a specific version of python itself via Uv scripts
I copied this from their website (https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...)
uv also respects Python version requirements: example.py
# /// script # requires-python = ">=3.12" # dependencies = [] # ///
# Use some syntax added in Python 3.12 type Point = tuple[float, float] print(Point)
> Using Python/UV to do anything more complex than my example PR above?
I can agree that this might be complex but that complexity has a trade off and of course nothing is shoe fits all but there are times when someone has to manage a complex CI environment and I looked at and there are some CI deterministic options too like invoke etc. and when you combine all of these, I feel like the workflow can definitely be interesting to say the least
Once again, I don't know what really ends up in github actions since I have never really used it properly, I am basing its critiques based on what I've read and what solutions (python came quite frequently) and something recently which I discovered (which was the blog)
Re: I hate GitHub Actions with passion
#203As much as I hate GitHub Actions, I prefer it over Jenkins and others, because it is right there. I don't need to go and maintain my own servers, or even talk to a 3rd party to host the services.
Like many things, the tool people reach for is the one that's in the box... As opposed to a trip to the hardware store, getting distracted for a few hours, coming back home and no longer in the mood to work on your project/choore.
Re: I hate GitHub Actions with passion
#204Earlier quoted context omitted.
there is quickemu which can install mac vm on linux (or any other host) rather quickly, what are your thoughts on it (I am an absolute quickemu shill because I love that software) https://github.com/quickemu-project/quickemu [ Quickly create and run optimised Windows, macOS and Linux virtual machines ]
Thank you so much for this... If I could +1 a dozen times I would.
Thanks! Glad I could help. If I may ask, what specific use case are you using quickemu for? Is it also for running mac machines on say linux?
Re: I hate GitHub Actions with passion
#205GH Actions isn't great compared to other CI systems, but it's also not particularly worse until you get into the nitty gritty details. The most important advice is probably to put as much code as possible into locally runnable scripts written in a cross-platform scripting language (e.g. Python or Node.js) to avoid 'commit-push-ci-failure' roundtrips. Only use the GH Actions YAML for defining the runtime environment a…
s/Node/Deno/ - direct repo/module references, no install step required.
Re: I hate GitHub Actions with passion
#206I take GitHub Actions over any of the other CI platforms.
Re: I hate GitHub Actions with passion
#207If you wanted a better version of GitHub Actions/CI (the orchestrator, the job definition interface, or the programming of scripts to execute inside those jobs), it would presumably need to be more opinionated and have more constraints? Who here has been thinking about this problem? Have you come up with any interesting ideas? What's the state of the art in this space? GHA was designed in ~2018. What would it look li…
I've been working for the last 5 years on an alternative called Dagger. Ended up building a company around it.
We started from the ideal state of CI, and set out to build the platform that would support that.
For us this ideal state of CI boils down to 4 things:
- local-first (local execution should be a first-class citizen, with no exception)
- repeatable (the same inputs should yield the same output, with affordances for handling inevitable side effects in an explicit and pragmatic way)
- programmable. my workflows are software. I want all the convenience of a modern software development experience: types, IDE support, a rich system API , debugging tools, an ecosystem of reusable components, etc.
- observable. I want all the information in one place about everything that happened in my workflow, with good tooling to get the information I need quickly, and interop with the existing observability ecosystem (eg. open telemetry)
So Dagger is our best effort at a CI platform focused on those 4 things.
Sorry if this comes across as a sales pitch. When you're building solves a problem you're obsessed with, it's hard to discuss the problem without also mentioning the solution that seems the most obvious to you :)
Re: I hate GitHub Actions with passion
#208This feels like a rage bait.
Re: I hate GitHub Actions with passion
#209If you wanted a better version of GitHub Actions/CI (the orchestrator, the job definition interface, or the programming of scripts to execute inside those jobs), it would presumably need to be more opinionated and have more constraints? Who here has been thinking about this problem? Have you come up with any interesting ideas? What's the state of the art in this space? GHA was designed in ~2018. What would it look li…
I've been working for the last 5 years on an alternative called Dagger. Ended up building a company around it. We started from the ideal state of CI, and set out to build the platform that would support that. For us this ideal state of CI boils down to 4 things: - local-first (local execution should be a first-class citizen, with no exception) - repeatable (the same inputs should yield the same output, with affordanc…
I've been watching Dagger with great interest, although have not moved production workloads to it (nor, admittedly, even committed an afternoon to setting up any workflows/graphs).
Passive comment readers should be aware that ^shykes here cofounded Docker (my gratitude), so it's really worth a look.
Can anyone comment on the ergonomics of Dagger after using it for a while?
I was just looking at the docs earlier this week to consider a migration but got confused by the AI sections...
Re: I hate GitHub Actions with passion
#210Earlier quoted context omitted.
Thank you so much for this... If I could +1 a dozen times I would.
Thanks! Glad I could help. If I may ask, what specific use case are you using quickemu for? Is it also for running mac machines on say linux?
That's what I intend to use it for, Mac and Windows... I'm starting on an app that I want to work cross platform (tauri/rust w/ react+mui) and want to be able to do manual testing or troubleshooting as needed on mac and windows without needing a separate machine.
My laptop is an M1 MacBook Air, and I do have an N100 I could use for Windows... I'd just assume use my fast desktop which even emulated is likely faster and not have to move seats.