41–50 of 98 posts
As an example not having Gitlab apps the same way Github apps has it is a bit of a disapointment for me since i generally like gitlab as company
Earlier quoted context omitted.
FWIW, while the UI for re-running jobs used to be better, the result was a LOT worse as it would re-run all the jobs instead of just the failing ones, so I am still MUCH happier with the new flow ;P.
I feel like those are not mutually exclusive. The button could say "Rerun failed jobs" no confirmation with a small ▼ next to it that has the other "rerun all jobs" drop down.
not to sound snarky, but what are you doing to address the 34 incident outages in the past 90 days? i feel like theres been no real update on this slow rolling disaster. we're not even a week into april and already a 5 hour outage in codespaces.
not to sound snarky, but what are you doing to address the 34 incident outages in the past 90 days? i feel like theres been no real update on this slow rolling disaster. we're not even a week into april and already a 5 hour outage in codespaces.
But I'm curious about what others think.
I've used GitHub Actions quite extensively now, across infrastructure automation, Python CI/CD, and iOS CI/CD, and while not perfect, it's the best platform I've used for this stuff so far. Compared to Jenkins it needed far less maintenance. Compared to CircleCI it felt much easier to work with and to build reliable pipelines due to the locking primitives it provides, and compared to Semaphore I found it easier to un…
GitHub Actions emphasizes reusability and composability around “actions” as installable packages suitable for a “marketplace” model. This works well, but once you deviate from a standard action, changing its behavior requires learning (or re-learning every six months) the GitHub Actions DSL to make it do what you want. This can be frustrating when it feels like you need to model your task to fit within an abstraction that didn’t help you in the first place.
GitLab CI feels much more “raw” and closer to the metal – there is less emphasis on packaging code into reusable workflows, and more emphasis on the practicalities of operating robust CI pipelines. Yes, you could have a different runner for every task, and “package” CI code into Docker images similarly to how GitHub Actions packages it into workflows. But the service isn’t designed around that idea. And for internal pipelines, that feels like a needless abstraction. It’s nice to keep pipelines simple and robust.
Put another way: there is much less “magic” in GitLab CI than in GitHub Actions. In many ways GitHub Actions feels more like a toy than a tool. This is generally a good thing, IMO, and overall I’d say the tradeoffs are worth it for both services, especially given the different contexts (internal vs. public code) in which we use them.
Earlier quoted context omitted.
Thanks for the feedback! I'm one of the PMs for GitHub Actions, and I appreciate this. Thinking about Actions as a set of primitives that you can compose is very much how I think about the product (and I think the other PMs as well) so I'm glad that resonates. We're always welcome to feedback, and we're continuing to invest and improve on the product, so I'm hopeful that we can address the features that you're missin…
Here's my ask: * Setting up GHA is still a lot of "commit and hope for the best". I've resorted to having a sandbox repo just for experimentation/testing so that I don't overly pollute repos that I actually care about. It would be great to get more instrumentation to see what is going on. * I have a monorepo for Dockerfiles. It's quite annoying that I have to have separate invocations for different Dockerfiles in dep…
As for the cache, we doubled it at the end of last year to 10GB. https://github.blog/changelog/2021-11-23-github-actions-cach..., but I can see how multi-arch images would be very large. Have you considered putting images into GitHub Container Registry instead of putting the layers into the cache? I'd love to understand if that is appropriate for your workflow, and if not, what the limitation there is.
Appreciate the rest of the feedback, I'll pass it along to the appropriate teams.
It's weird to me that GitHub doesn't have larger machines types available for actions yet. I don't want to bother with a self-hosted runner just to get more CPUs. They have much larger machines available for Codespaces - why not actions? I'm happy to pay for them.
Check us out here: https://buildjet.com/for-github-actions
It's weird to me that GitHub doesn't have larger machines types available for actions yet. I don't want to bother with a self-hosted runner just to get more CPUs. They have much larger machines available for Codespaces - why not actions? I'm happy to pay for them.
Earlier quoted context omitted.
I don't think it's too hot a take, but it is incorrect. Dependabot Alerts (and Updates) are required on all internal services and folks use them (and provide similar feedback). Dependabot Alerts is working on some of these things, starting with e.g. https://github.blog/changelog/2022-02-08-dependabot-alerts-p... I know that security alerts in general are working on ways of assigning alerts (or opening issues that ref…
Do you know why a repo might be getting dependabot alerts when it used to have them setup, but now it doesn't, yet still gets them randomly?
I'd also check and make sure Updates is turned off (delete the dependabot.yml).