5 ms·

Supercharging GitHub Actions with Job Summaries

139 points by judge2020 4y ago

bin_bash 4y ago
Very clever to use markdown for this: makes it easy to implement on both sides. I would've probably done some kind of custom table DSL which would've been way worse.
unboxingelf 4y ago
Nit: love the usage of emojis for quickly conveying information, but do use them consistently. In this example they’re using both a ‘red x’ and a ‘red dot’ for failures. Similarly, they use both tenses “Failed” and “Fail”, “Passed” and “Pass”. Pick one and stick with it.
- bilalq 4y ago
  This is definitely a nice feature. I had previously tried creating workflow jobs that had emojis in their name, but that wasn't supported.
- hnbad 4y ago
  FWIW "Failed"/"Passed" vs "Fail"/"Pass" is aggregates vs individual result, so I'd give them a pass (heh) on that one.
junon 4y ago
"Supercharging" is such an exhausting buzzword these days...
- mirntyfirty 4y ago
  I feel similarly about “powered by.”
- smcleod 4y ago
  Agreed, more like "Should have been there since day 1 and we know we still don't have a decent deploy dashboard"
encryptluks2 4y ago
I can't help but feel like GitHub is like 5 years behind GitLab.
- hatware 4y ago
  They also put generic DRY features like 'internal' repos behind their most expensive paywall. Thanks M$.
  - aeyes 4y ago
    Looking at the pricing page I see "unlimited public/private repositories" in their free "plan". Could you explain what type of internal repos you are talking about?
    - hatware 4y ago
      Internal repositories, for example, make it easier to have one set of Git Actions that is available to any Git Actions runner in your Org. What this means in practical terms, is cleaner code that is less repetitive. It's a total cop-out for GH to act like this is a feature worth paying for enterprise. It's not just useful to enterprise users, it's useful to everyone, including free users. TL;DR: GH encourages bad coding practices unless you pay them enough. It's not consumer friendly and they can barely keep Actions running consistently enough to justify a paywall for such a staple feature.
      - dboreham 4y ago
        I suspect parent is asking you to explain how this is different than a "private" repository.
        hatware 4y ago
        Private repositories can only be used by the Git Actions runner for that repository. For a monorepo, this works fine. If you have any semblance of microservices in their own repos, orchestrating CI/CD and other build/artifact processes is a nightmare. Internal repositories allow the Git Actions runner access from any other private repository, meaning you can have one repository for all of your git actions that can be neatly called from any other repository (private or public) in the org.
simonw 4y ago
I love the design of this! echo '### Hello world! :rocket:' >> $GITHUB_STEP_SUMMARY Having this as an environment variable you can write to that is really clever, and makes it easy to generate these from other scripts (or Python commands etc) too.
- jffry 4y ago
  Small clarification, because I had the same misconception: $GITHUB_STEP_SUMMARY is just an env var containing the name of a file
  - simonw 4y ago
    Yeah https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary https://docs.github.com/en/actions/using-workflows/workflow-... has some more details on this - it even suggests that if you want to delete the summary entirely you can do: rm $GITHUB_STEP_SUMMARY
  - divbzero 4y ago
    Thanks, it was fuzzy at first to me as well. The official description of $GITHUB_STEP_SUMMARY reveals a bit of the implementation details: > The path on the runner to the file that contains job summaries from workflow commands. This file is unique to the current step and changes for each step in a job. For example, /home/rob/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c. https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables https://docs.github.com/en/actions/learn-github-actions/envi...
lloydatkinson 4y ago
This is great, I've been wanting unit test results to be outputted like this for ages. Same for IaC setups, to have the URL to a newly created environment easily clickable, etc.
juanbyrge 4y ago
I am surprised to see that GitHub staff are still working on GitHub Actions. It's hard to tell because it's been almost two years and it's still not possible to have a self-hosted GitHub Actions runner on Mac M1: https://github.com/actions/runner/issues/805 https://github.com/actions/runner/issues/805, even though the community has made PRs for it.
- Dayshine 4y ago
  People use mac m1s as servers?
  - leodriesch 4y ago
    Mostly the Mac Mini to run CI workflows or build iOS and macOS applications.
  - nicoburns 4y ago
    Macs are the only way to build iOS apps. And the M1 macs are several times faster at this task than the old ones.
- rethab 4y ago
  GitHub Actions are extremely actively developed and from what I can tell quite strategic. However, the action team's acceptance for outside contributions across all their projects (runner, toolkit, actions) seems surprisingly low for a company that runs a "social" coding service.
- threeseed 4y ago
  This is seriously bizarre. Arguably the world's leading CI/CD tool doesn't support iOS builds on M1. But yet they can deliver 100+ far less fundamental features: https://github.blog/changelog/ https://github.blog/changelog/
- sascha_sl 4y ago
  Self-hosted runners at scale are a nightmare. Random failures all around, exit code is whatever it wants to be... you'd think with the runner code in the open all that could be fixed, but no, it's a very confusingly written MS C# codebase that has clearly grown over the years as TFS Pipelines. Even the GitHub developers get confused when they tried to implement ephemeral runners and then figured out the scheduler just pipelines new jobs to runners and drops them permanently (shows as "waiting for runner for 15-20 minutes, then cancelled to the user) if you kill the runner anyway. And the worst: The component failing most often is the scheduler, and that runs at GitHub. It feels like it was written by an intern. It doesn't even do FIFO. Old jobs generally wait _longer_. We also have stuck jobs all the time because the scheduler lost it. GitHub Premium Enterprise Support just keeps saying to contact them whenever it happens and they're "working on it". My team has been working on making this entire crap work for almost an entire year on and off, and things only got marginally better. To the point we'll be using the new hosted runners with fixed egress IP and custom sizes instead. Good job, you filled a hole in your spec sheet with literal shit and then sold us the only alternative a year later when it is unfeasible to migrate away again ("but we have a large Microsoft contract" politics keep us from doing that anyway, but that aside).
sebyx07 4y ago

139 points by judge2020 4y ago

Very clever to use markdown for this: makes it easy to implement on both sides. I would've probably done some kind of custom table DSL which would've been way worse.

unboxingelf 4y ago

Nit: love the usage of emojis for quickly conveying information, but do use them consistently. In this example they’re using both a ‘red x’ and a ‘red dot’ for failures. Similarly, they use both tenses “Failed” and “Fail”, “Passed” and “Pass”. Pick one and stick with it.

bilalq 4y ago
This is definitely a nice feature. I had previously tried creating workflow jobs that had emojis in their name, but that wasn't supported.
hnbad 4y ago
FWIW "Failed"/"Passed" vs "Fail"/"Pass" is aggregates vs individual result, so I'd give them a pass (heh) on that one.

junon 4y ago

"Supercharging" is such an exhausting buzzword these days...

mirntyfirty 4y ago
I feel similarly about “powered by.”
smcleod 4y ago
Agreed, more like "Should have been there since day 1 and we know we still don't have a decent deploy dashboard"

encryptluks2 4y ago

I can't help but feel like GitHub is like 5 years behind GitLab.

hatware 4y ago
They also put generic DRY features like 'internal' repos behind their most expensive paywall. Thanks M$.
- aeyes 4y ago
  Looking at the pricing page I see "unlimited public/private repositories" in their free "plan". Could you explain what type of internal repos you are talking about?
  - hatware 4y ago
    Internal repositories, for example, make it easier to have one set of Git Actions that is available to any Git Actions runner in your Org. What this means in practical terms, is cleaner code that is less repetitive. It's a total cop-out for GH to act like this is a feature worth paying for enterprise. It's not just useful to enterprise users, it's useful to everyone, including free users. TL;DR: GH encourages bad coding practices unless you pay them enough. It's not consumer friendly and they can barely keep Actions running consistently enough to justify a paywall for such a staple feature.
    - dboreham 4y ago
      I suspect parent is asking you to explain how this is different than a "private" repository.
      - hatware 4y ago
        Private repositories can only be used by the Git Actions runner for that repository. For a monorepo, this works fine. If you have any semblance of microservices in their own repos, orchestrating CI/CD and other build/artifact processes is a nightmare. Internal repositories allow the Git Actions runner access from any other private repository, meaning you can have one repository for all of your git actions that can be neatly called from any other repository (private or public) in the org.

simonw 4y ago

I love the design of this! echo '### Hello world! :rocket:' >> $GITHUB_STEP_SUMMARY Having this as an environment variable you can write to that is really clever, and makes it easy to generate these from other scripts (or Python commands etc) too.

jffry 4y ago
Small clarification, because I had the same misconception: $GITHUB_STEP_SUMMARY is just an env var containing the name of a file
- simonw 4y ago
  Yeah https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary https://docs.github.com/en/actions/using-workflows/workflow-... has some more details on this - it even suggests that if you want to delete the summary entirely you can do: rm $GITHUB_STEP_SUMMARY
- divbzero 4y ago
  Thanks, it was fuzzy at first to me as well. The official description of $GITHUB_STEP_SUMMARY reveals a bit of the implementation details: > The path on the runner to the file that contains job summaries from workflow commands. This file is unique to the current step and changes for each step in a job. For example, /home/rob/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c. https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables https://docs.github.com/en/actions/learn-github-actions/envi...

lloydatkinson 4y ago

This is great, I've been wanting unit test results to be outputted like this for ages. Same for IaC setups, to have the URL to a newly created environment easily clickable, etc.

juanbyrge 4y ago

I am surprised to see that GitHub staff are still working on GitHub Actions. It's hard to tell because it's been almost two years and it's still not possible to have a self-hosted GitHub Actions runner on Mac M1: https://github.com/actions/runner/issues/805 https://github.com/actions/runner/issues/805, even though the community has made PRs for it.

Dayshine 4y ago
People use mac m1s as servers?
- leodriesch 4y ago
  Mostly the Mac Mini to run CI workflows or build iOS and macOS applications.
- nicoburns 4y ago
  Macs are the only way to build iOS apps. And the M1 macs are several times faster at this task than the old ones.
rethab 4y ago
GitHub Actions are extremely actively developed and from what I can tell quite strategic. However, the action team's acceptance for outside contributions across all their projects (runner, toolkit, actions) seems surprisingly low for a company that runs a "social" coding service.
threeseed 4y ago
This is seriously bizarre. Arguably the world's leading CI/CD tool doesn't support iOS builds on M1. But yet they can deliver 100+ far less fundamental features: https://github.blog/changelog/ https://github.blog/changelog/
sascha_sl 4y ago
Self-hosted runners at scale are a nightmare. Random failures all around, exit code is whatever it wants to be... you'd think with the runner code in the open all that could be fixed, but no, it's a very confusingly written MS C# codebase that has clearly grown over the years as TFS Pipelines. Even the GitHub developers get confused when they tried to implement ephemeral runners and then figured out the scheduler just pipelines new jobs to runners and drops them permanently (shows as "waiting for runner for 15-20 minutes, then cancelled to the user) if you kill the runner anyway. And the worst: The component failing most often is the scheduler, and that runs at GitHub. It feels like it was written by an intern. It doesn't even do FIFO. Old jobs generally wait _longer_. We also have stuck jobs all the time because the scheduler lost it. GitHub Premium Enterprise Support just keeps saying to contact them whenever it happens and they're "working on it". My team has been working on making this entire crap work for almost an entire year on and off, and things only got marginally better. To the point we'll be using the new hosted runners with fixed egress IP and custom sizes instead. Good job, you filled a hole in your spec sheet with literal shit and then sold us the only alternative a year later when it is unfeasible to migrate away again ("but we have a large Microsoft contract" politics keep us from doing that anyway, but that aside).

sebyx07 4y ago