[HN Gopher] We use GitHub Actions to build GitHub
___________________________________________________________________
We use GitHub Actions to build GitHub
Author : todsacerdoti
Score : 87 points
Date : 2022-04-05 15:52 UTC (7 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| danpalmer wrote:
| 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 understand how the pieces fit
| together.
|
| My criticism would mostly be about missing features, but the pace
| of development has been great and the only one I have left on my
| list is SSH debugging, which didn't end up being much of a
| blocker to our adoption anyway.
|
| As for reliability, nothing is perfect, but in my experience it's
| at-or-above the level that CircleCI provided, and far surpassed
| our in-house Jenkins server.
| judge2020 wrote:
| > 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.
| ethomson wrote:
| 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.
| explorigin wrote:
| 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.
| zhfliz wrote:
| fwiw, you can use approvals using environments:
| https://docs.github.com/en/actions/deployment/targeting-
| diff...
| OJFord wrote:
| That's very much how I think about it too, which is why it
| frustrates me that I can't create canned workflows that apply
| to all my repos of a certain type (language specific linting
| and releasing say).
|
| I know I can create user/organisation templates, but all that
| does is put it in the UI chooser to create a commit to put it
| in the repo from the web. I want to do something like
| `include: OJFord/workflows/terraform-provider.yml` or
| `include: OJFord/workflows/rust.yml`
|
| Perhaps even better would be I don't even have to specify
| that in the repo, they just apply automatically to any which
| match a given pattern - named `terraform-provider-*` or
| having a file `Cargo.toml` say - but I realise that's
| probably too big a deviation from the way Actions works at
| this point.
| judge2020 wrote:
| This might be what you're looking for:
| https://github.com/github/roadmap/issues/74
| a_t48 wrote:
| Could you stuff your actions definition into a sub module
| pointed at trunk?
| OJFord wrote:
| Interesting idea! Even if Actions will follow a submodule
| though (I doubt it tbh, it happens before any actions run
| of course so we have no control over that) you can't
| point it 'at trunk' as far as I know, they're always at a
| specific commit.
|
| (E.g. if you git submodule foreach git checkout master,
| your diff if you have one will be updating commit hashes,
| not -whatever +master. This is good for a lot of other
| reasons but doesn't help here.)
| newman314 wrote:
| 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?
| lapser wrote:
| > 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.
|
| There is act[0] which aims to let you run github actions
| locally via Docker. It isn't perfect but it does a decent
| job at it, and for the most part your pipeline can be run
| locally.
|
| After MS bought GH, I had hopes that they would build a
| tool to run action locally, but nothing yet.
|
| [0] https://github.com/nektos/act
| OJFord wrote:
| I've had no luck reproducing problems in Actions with
| act, and the rest of the time have problems in act that I
| don't in Actions it seems.
|
| I like the idea and also would like something first-
| party, but I imagine it's hard and GitHub would want it
| to be less buggy than act is, and maybe they're trying
| but it's not there.
|
| Tbh even if it ran remotely in actual Actions, but just
| didn't show up in the repo UI, logged locally, that would
| be fine?
| ethomson wrote:
| Thanks. The "commit and hope for the best" problem really
| resonates with me. There are two great projects that might
| provide some pain relief - nektos/act or rhysd/actionlint.
| But I agree that commit-to-validate is probably the best
| strategy at the moment, which is deeply unfortunate. This
| is an area that I intend to improve in the future.
|
| 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.
| chatmasta wrote:
| We use GitLab CI for internal code and GitHub Actions for
| public code, and are generally happy with both.
|
| 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.
| [deleted]
| ossusermivami wrote:
| As someone who has been working with apis from all the major git
| platforms, i find the Github api the most complete and most
| featureful to work with..
|
| 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
| ewhauser421 wrote:
| 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.
| thinkafterbef wrote:
| Hey founder of BuildJet here, With BuildJet for GitHub Actions,
| you can get up to 64 vCPU as a GitHub Actions runner. We plug
| right into your existing setup and have a significantly higher
| per core performance compared to the native runner.
|
| Check us out here: https://buildjet.com/for-github-actions
| hayd wrote:
| I this is in preview, I've seen it in a few projects (ubuntu-
| latest-xl), so perhaps we'll see wider release soon?
| nimbius wrote:
| 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.
| yowlingcat wrote:
| I've had multiple meetings with my team in the past month about
| what our contingency plan is for moving off GH if need be. It's
| gotten that bad. So far, we've gotten to "well I guess GitLab
| is available and we can put it behind a VPN" and punted on
| talking about it any further.
|
| But I'm curious about what others think.
| uuyi wrote:
| This is my biggest concern. The more we centralise on GitHub,
| the more we centralise the risk on a service which goes down
| harder and more often than our Jenkins infrastructure did.
| emsy wrote:
| How Github uses Github (Actions) to build Github. Yes I'm this
| old.
| WhyNotHugo wrote:
| In other news, Mercedes executives drive Mercedes cars.
| ctvo wrote:
| Is that why it's down all the time? _bazing_ I 'll show myself
| out.
| dudeinjapan wrote:
| Github Actions folks if you're listening, please address lack of
| "Allow Failure" modifier for job runs. There is a reason every
| other CI on the planet has this, and no, it's not the same as
| "Continue on Error" https://github.com/actions/toolkit/issues/399
| (currently 800+ upvotes and counting)
| stickfigure wrote:
| 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.
| savanaly wrote:
| This is why UI is hard. In a parallel universe they made the
| re-run jobs button like you want, and there's some person at
| the top of the Hacker News comments in that universe making the
| complaint that it's too hard to tell what the buttons do, and
| that only the common path of rebuilding failed builds is easy
| and once you need to do something uncommon it becomes
| irritatingly complex.
| hamandcheese wrote:
| Why have one button? Why not one button for the workflow,
| plus one button next to each job?
|
| Buildkite gets this right.
| bastardoperator wrote:
| Why would you want to context shift to a UI anyways? I would
| argue slack is a better place to get notifications.
| gregmac wrote:
| > because of some flakey third-party service
|
| I've started building in auto retries to the CI scripts for
| this type of thing, at least once it annoys me to a certain
| extent. The most glaring and unavoidable ones that come to mind
| across several projects are external certificate time stamping
| services.
|
| I generally hate this type of thing: retry mechanisms are a
| lazy band-aid that can mask real problems. But at the same
| time, it just isn't possible to get to 100% and retry is a
| better band-aid than constant human intervention.
| saurik wrote:
| 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.
| booi wrote:
| I feel like those are not mutually exclusive. The button
| could say "Rerun failed jobs" no confirmation with a small V
| next to it that has the other "rerun all jobs" drop down.
| saurik wrote:
| Oh yeah: I am not intending to mean that the new UI is
| good, only that it is still somehow better than the old
| flow ;P.
| OJFord wrote:
| If you're already putting your own frontend on it in Slack, you
| could add a 're-run' button to that failure notification that
| hits the API for that? (I assume there is one.)
|
| There's a weird DSL for buttons/layout in Slack, but it works,
| and obviously it's pretty easily testable, just fire the
| examples at your own endpoint and tweak it until it does what
| you want.
|
| My own main frustration with Actions is just that the docs are
| bad, making it hard to configure.
| Dachande663 wrote:
| We switched to buddy.works[0] about a year ago and honestly it's
| just been... smooth. The UI is just great, the wealth and breadth
| of options is ever increasing and all the basics like knowing
| what went wrong, restarting, debugging, duplicating etc just work
| as you'd expect. One of the few companies I can recommend.
|
| [0] https://buddy.works
| candiddevmike wrote:
| How does GitHub fix GitHub using GitHub when GitHub is down?
| incel wrote:
| They probably have some sort of development test server. That
| what I'd do.
| rvz wrote:
| Obviously they internally self-host a version of GitHub Actions
| to build GitHub itself.
|
| They know how unreliable it is to use the live version to do
| it.
| sdab wrote:
| I don't know what github is doing here, but I've seen this
| antipattern quite a few times in production at some big name
| companies...
| watermelon0 wrote:
| Maybe they use GitHub Enterprise Server to host internal
| repositories?
| glouwbug wrote:
| I wonder if JIRA uses JIRA to track itself
| and0 wrote:
| They do, actually! All of the public help requests and feature
| suggestions have been in Jira since, like, the early 00s. It's
| weird to see when they pop up in Google results with ancient
| screenshots attached.
| lloydatkinson wrote:
| " 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.
| bbrree66 wrote:
| Rapzid wrote:
| 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 no history on the alert to see why an "opened 6 months ago"
| alerts suddenly appeared
|
| * Alerts that can't have PR fixes opened because "The vulnerable
| package is no longer used"(paraphrasing) are still open.. Why?
|
| Such a lackluster area of the product it has me wanting to give
| Snyk(blarghh) another look or some other alternatives.
| asciimike wrote:
| 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)
| lloydatkinson wrote:
| 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?
| asciimike wrote:
| Hate to say it but have you tried turning it on and off
| again? IIRC sometimes the state of alerts got stuck in a
| weird place and resulted in the incorrect state. Toggling
| it might put it back into the desired state.
|
| I'd also check and make sure Updates is turned off (delete
| the dependabot.yml).
| lloydatkinson wrote:
| Well there's no yml file at all which is the confusing
| part but I suppose I could try make a blank one
| danpalmer wrote:
| 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?
| asciimike wrote:
| 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)
| havs wrote:
| (Disclosure: current PM for Dependabot Alerts, currently
| working at GitHub)
|
| You're right -- we haven't invested nearly enough in Dependabot
| Alerts. We're working to change that, starting with some
| foundational improvements like alert persistence, which shipped
| in February. (https://github.blog/2022-02-08-improving-
| developer-experienc...)
|
| After our recent ship, we're in good shape to start addressing
| some of your concerns, like greater clarity through an alert's
| lifecycle or comments with dismissal.
|
| Would love to hear any additional feedback. Let me know!
___________________________________________________________________
(page generated 2022-04-05 23:01 UTC)