It's not really context switching. Author is debugging github actions, thats the context in which a few window changes seem minor. Context switching would be to get dragged to meeting, or getting asked by a colleague to explain how to set up github actions for their project.
GitHub Actions could be so much better
151–160 of 238 posts
Re: GitHub Actions could be so much better
#152Can I trigger a workflow from a different workflow yet? That seems very basic, and last time I looked I had to create a token that gives read/write access to every repo in every organization to do this. And then it didn't work because the docs for the trigger API is apparently wrong.
Re: GitHub Actions could be so much better
#153Github Actions has been a pleasant introduction to CI/CD for me. I used to build locally and then git push and/or rsync everything directly to a VPS (Digitalocean Droplets in my case). But for collaboration, this workflow breaks down. Then, using Github as the "origin" repository becomes compelling, and Github Actions fit very nicely with that workflow.
Re: GitHub Actions could be so much better
#154Another tool that tackles GitHub Action debugging head on:
https://www.ci-debugger.io/
Wrap your GH Actions in a debugger breakpoint and connect into the live broken GH Action to inspect the machine, re-run commands etc..
At it's heart - realtime debugging for GitHub actions.
Re: GitHub Actions could be so much better
#155I couldn't agree more with the pain of debugging a GH Actions run. The /only/ tool you have is the ability to re-run with debug on. That's it. I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks. Very basic things, like having reusable logic, is needlessly complex or poorly documented. Once I figured out how to do it it was fairly ea…
If only competitors could do better... https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2797
yeah... https://github.com/firecow/gitlab-ci-local is a good workaround but should be built-in. How do developers at GitLab/Github debug their workflows?
Re: GitHub Actions could be so much better
#156My number one complaint is that they still don't have managed ARM runners. Considering how overpriced runners are (compared to cloud instances), I'm sure they would make a ton of money here. My choices here are either to use a different CI solution (but I quite like Actions, and they are better integrated in the Github UI than alternatives), or to use custom self-hosted autoscaling runners (but there doesn't appear t…
Check out https://dime.run/ they manage workers for you
Re: GitHub Actions could be so much better
#157There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…
Your advice is sane and I can tell speaks from experience. Unfortunately, now that Github Actions are being exposed through Visual Studio, I fear that we are going to see an explosion of number 1, just because the process is going to be more disconnected from Github itself (no documentation or Github UI visible while working within Visual Studio).
Re: GitHub Actions could be so much better
#158The git commit, push, wait loop is terrible UX. Users deserve portable pipelines that run anywhere, including their local machines. I understand Act [1] goes some way to solving this headache but it's by and large not a true representation. There are many pipelines you can't run locally, because they're production, for example, but there's no reason why we can't capture these workflows to run them locally at less-cri…
We need Terraform for build pipelines and God help you if you use Bitbucket lol
Re: GitHub Actions could be so much better
#159GitHub Actions is a horrible CI/CD system. You cannot run steps in parallel on the same VM; container-based workloads are a second-class citizen. The first problem means that setting up local credentials and other environment dependencies cannot be parallelized (I'm looking at you, google-github-actions/setup-gcloud, with your 1m+ runtime... grrr), the second makes it quite difficult to put a Dockerfile in a reposito…
> Of course, sometimes the cache isn't found, particularly because there's a 5 GB cache size limit (which cannot be enlarged, not even for payment) which cycles out FIFO. So if you go over the 5 GB cache, you might as well not have one.
Looks like I can move on that "build caching mysteriously broken" issue now. Thanks for the heads up!
Re: GitHub Actions could be so much better
#160There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…
I appreciate this perspective, however, after spending 6mo on a project that went (2) all the way, never again. CI/CD SHOULD NOT be using the same scripts you build with locally. Now, we have a commit that every dev must apply to the makefile to build locally, and if you accidentally push it, CI/CD will blow up (requiring an interactive rebase before every push). However, you can’t build locally without that commit.
I won’t go into the details on why it’s this way (build chain madness). It’s stupid and necessary.