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

51–60 of 98 posts

Re: We use GitHub Actions to build GitHub

#51

Post by OJFord »

a_t48 wrote: post #37
OJFord wrote: post #26

Earlier quoted context omitted.

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-pro…

Could you stuff your actions definition into a sub module pointed at trunk?

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

Re: We use GitHub Actions to build GitHub

#53

Post by hamandcheese »

savanaly wrote: post #24
stickfigure wrote: post #16

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…

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.

Why have one button? Why not one button for the workflow, plus one button next to each job?

Buildkite gets this right.

Re: We use GitHub Actions to build GitHub

#54

Post by lloydatkinson »

asciimike wrote: post #50
lloydatkinson wrote: post #15

Earlier quoted context omitted.

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?

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

Well there's no yml file at all which is the confusing part but I suppose I could try make a blank one

Re: We use GitHub Actions to build GitHub

#55

Post by telotortium »

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…

> SSH debugging

Have you seen https://github.com/marketplace/actions/debugging-with-ssh? (Maybe this only works with public Github - that's all I use). I add an `if: ${{ failure() }}` to only spawn the SSH when my job fails and use that to debug CI issues.

Re: We use GitHub Actions to build GitHub

#56

Post by WhyNotHugo »

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…

It's definitely more pleasant to use than Jenkins, but Jenkins is as painful as it gets.

90% of the times it's some ancient setup that nobody knows how it works. And the amount of hands-on required to keep in working is waaaay higher than other CI pipelines.

Circle CI is also not very nice at all. Things like GitLab CI or Sourcehut Builds are sooo much simpler, lighter and faster in comparison.

Re: We use GitHub Actions to build GitHub

#57

Post by explorigin »

zhfliz wrote: post #35
explorigin wrote: post #20

Earlier quoted context omitted.

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.

fwiw, you can use approvals using environments: https://docs.github.com/en/actions/deployment/targeting-diff...

Sure, but that's actually worse than useless for my use-case. Image this, you have an action that publishes your plan to your PR (#1 - it's a biggish feature). It gets merged and goes to approval. Then people happen. PR #2 is addressing a customer-facing bug so it gets fast-tracked and rammed through before PR #1. Suddenly PR #1 is silently invalid. It _should_ be rejected at this point but the whole point of CI/CD is to save time and reduce the surface area for human mistakes.

Re: We use GitHub Actions to build GitHub

#58

Post by DoctorDabadedoo »

and0 wrote: post #29
glouwbug wrote: post #19

I wonder if JIRA uses JIRA to track itself

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.

And it's still awful.

Re: We use GitHub Actions to build GitHub

#59

Post by zhfliz »

explorigin wrote: post #57
zhfliz wrote: post #35

Earlier quoted context omitted.

fwiw, you can use approvals using environments: https://docs.github.com/en/actions/deployment/targeting-diff...

Sure, but that's actually worse than useless for my use-case. Image this, you have an action that publishes your plan to your PR (#1 - it's a biggish feature). It gets merged and goes to approval. Then people happen. PR #2 is addressing a customer-facing bug so it gets fast-tracked and rammed through before PR #1. Suddenly PR #1 is silently invalid. It _should_ be rejected at this point but the whole point of CI/CD i…

specifically for your terraform example, wouldn't it make more sense to have the PR merged only when apply was successful?

i'm not sure how well that can be represented in GH actions, but that would surely be the better option?

you'll always risk some kind of race condition there, e.g. atlantis locks the project while something is planned but not applied to avoid such things from happening. this of course prevents having multiple PRs "ready" at the same time, you'd have to unlock the active PR lock to be able to implement another one.

Re: We use GitHub Actions to build GitHub

#60

Post by rsclarke »

I've been capturing a list of GitHub Actions gotchas;

1. If you reference an environment in a build step, this causes an `on: deployment` event trigger. This is not intuitive.

2. Environments with deployment protection rules are just for branches. Using tagged releases for a production environment means we must allow all branches to be deployed to that environment.

3. Workflows are unable to start other workflows to prevent cyclic actions. Understandable, there are exceptions however e.g (1) above.

4. Pull requests raised by Dependabot will not have the `id-token: write` permission needed to create an OIDC ID token that we use to access external systems (the benefit of then not having to manage secrets). Note: Using `on: pull_request_target` will be granted the permission but then you're executing the `main` branch and not building/testing the Dependabot changes.

Then we have secrets, Organisation, Repository, Environment and Dependabot. Anything in Organisation, Repository or Dependabot should really be at most read only permissions. Environment based secrets may have write permissions but be wary of the malicious PR that then references this environment, what protections are in place? Environment approval? Deployment branch protection?

Post reply on HN