Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We use GitHub Actions to build GitHub

github.blog

Post reply on HN
Print view View original

11–20 of 98 posts

Re: We use GitHub Actions to build GitHub

#11

Post by judge2020 »

danpalmer wrote: post #6

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…

> My criticism would mostly be about missing features,

My only real requested feature is one that's been open since early 2020 (this issue replaced the old 2020 issue) and has the status "Status: Q1 2022 – Jan-Mar" https://github.com/github/roadmap/issues/161

Without this, i'm relying on Azure actions to start/stop+deallocate a self-hosted runner, which adds ~1 minute to the job startup time.

Re: We use GitHub Actions to build GitHub

#12

Post by ethomson »

danpalmer wrote: post #6

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…

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 missing.

Re: We use GitHub Actions to build GitHub

#13

Post by asciimike »

Rapzid wrote: post #5

Hot take; they don't use their security alerts to manage dependency vulnerabilities. Sorry, taking this on a tangent but the security alerts feature as integrated into the product is WAY less usable than other features, such as actions. Just off the top of my head: * No way to assign alerts to people * No free-form comments when dismissing alerts? * Old alerts re-open if a regression introduces the change back.. With…

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 reference those alerts)--hopefully this is something that will show up soon.

(Disclosure: former Dependabot PM, no longer work at GitHub)

Re: We use GitHub Actions to build GitHub

#14

Post by asciimike »

danpalmer wrote: post #7
Rapzid wrote: post #5

Hot take; they don't use their security alerts to manage dependency vulnerabilities. Sorry, taking this on a tangent but the security alerts feature as integrated into the product is WAY less usable than other features, such as actions. Just off the top of my head: * No way to assign alerts to people * No free-form comments when dismissing alerts? * Old alerts re-open if a regression introduces the change back.. With…

I haven't used the security alerts, but isn't the idea that you open an issue and then track it there using the regular project management tools? > Snyk(blarghh) What's wrong with Snyk?

That's how everyone does it today, but given that GitHub has an issues product, it really should be better integrated.

The main issue is that issues are publicly viewable, while security alerts are only available to certain users (e.g. repo admins). Since repo owners of e.g. popular OSS repos might not want public issues around their security vulnerabilities, this isn't something that's been actioned.

Should GitHub offer more granular permissions on issues to resolve this? Probably, but unfortunately that's reaching fairly deep into how GitHub works today.

(Disclosure: former Dependabot PM, no longer at GitHub)

Re: We use GitHub Actions to build GitHub

#15

Post by lloydatkinson »

asciimike wrote: post #13
Rapzid wrote: post #5

Hot take; they don't use their security alerts to manage dependency vulnerabilities. Sorry, taking this on a tangent but the security alerts feature as integrated into the product is WAY less usable than other features, such as actions. Just off the top of my head: * No way to assign alerts to people * No free-form comments when dismissing alerts? * Old alerts re-open if a regression introduces the change back.. With…

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?

Re: We use GitHub Actions to build GitHub

#16

Post by stickfigure »

GitHub Actions has a lot of basic usability issues, none of which are fatal but all of which irritate me on a daily basis.

Let's start with the first and simplest: Why did my build fail? You'd think this should be front and center. Yet, the UX is "click through a couple links, then wade through thousands of lines of log output". In practice this is "download the logs and grep them for text strings like FAILURE".

The only way we've made this livable is by writing action code that sends test failures to a slack channel, and more or less ignoring the GitHub UI.

Second usability issue: Restarting a build. Happens all the time because of some flakey third-party service. It's pretty much my primary interaction with the GitHub Actions UI.

1. Click on build name

2. Click on "Re-run jobs" which brings down a dropdown menu

3. Click on "Re-run failed jobs" menu item

4. Click on "Re-run jobs" button on the confirm dialog

Seriously, after five times going through this flow I'm screaming for a JUST RERUN THE FUCKING JOBS ALREADY button. What's annoying is that this used to be better - the dropdown and confirm dialog are recent additions. The UX is degenerating.

The irony is that we migrated from CircleCI because they were screwing up their UX, and we figured GitHub would make something better... sigh.

Re: We use GitHub Actions to build GitHub

#17

Post by lloydatkinson »

" Turn weekly team photos into GIFs and upload to README"

Well, as a remote worker that has my camera off as much as possible out of principle I'd really hate this. It actually puts me off applying knowing glimpses of my home get turned into GIFs for the entire company to see.

Re: We use GitHub Actions to build GitHub

#18

Post by newman314 »

ethomson wrote: post #12
danpalmer wrote: post #6

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…

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 dependabot.yml. I should be able to specify /Dockerfile or /Dockerfile* as patterns for detection. The Dependabot invocation for GitHub Actions is a single entry and it would be great to have that.

* I quite like Step Security's Harden Runner but it does require more work/invocations to get this set up. Maybe GH can work with them to more closely incorporate said functionality?

* Make the cache bigger? I build a fair number of multi-arch containers and starting all of them at once tends to blow out the cache.

* Given the interest around sigstore and SBOMs, maybe incorporate native capabilities to sign artifacts and generate SBOMS?

Re: We use GitHub Actions to build GitHub

#20

Post by explorigin »

ethomson wrote: post #12
danpalmer wrote: post #6

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…

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…

From my perspectives, GHA is missing 2 things over CircleCI. A way to pause an action for approval, or a way to pull artifacts from other workflows. Both of these actions are _possible_ with an external service but painful to setup. I want to: create a terraform plan, approve it, and then deploy the specifically approved plan. That's not so difficult in CircleCI but is _painful_ in GHA.
Post reply on HN