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

GitHub Actions Pitfalls

fusectore.dev

Post reply on HN
Print view View original

71–80 of 111 posts

Re: GitHub Actions Pitfalls

#71

Post by Floegipoky »

throwawayuydw wrote: post #24
speedgoose wrote: post #12

I believe pull request from forks are not triggered by default because some people where using this to mine cryptocrap on cpu using the quotas of other projects.

Quoted post unavailable.

The tech industry is like the Wild West- you can do (almost) anything you want! It's big enough that there will always be opportunities in our lifetime for tech workers to make money positively contributing to society. On the other hand, there's plenty of funding for exploitative/harmful applications. It doesn't matter what other people are doing or have done, your choice and your integrity belong to you.

Re: GitHub Actions Pitfalls

#73

Post by newman314 »

I generally like Actions but occasionally run into limitations (possibly my own).

For example, I'd like to build an action that triggers a documentation update based on the path and filename that is changed.

  on:
    push:
      branches: 
        - main
      paths:
        - */README.md
But there does not appear to be a way to pass a list of changed paths to the job.

Re: GitHub Actions Pitfalls

#74

Post by jacobyoder »

bilalq wrote: post #63

A few other pitfalls: * Scheduled actions basically never run anywhere close to on schedule. If you schedule something to run every 13 minutes, it may just run 1-3 times an hour with random 30 minute to 1 hour waits in between executions. * Triggering a workflow as a result of an action from another workflow doesn't work if you're using the GITHUB_TOKEN as part of the action. Github does this to prevent accidental re…

Yet another pitfall: Changing the system clock on runners can throw off billing and calculation of used minutes. Colleague of mine told me about that one last year.

Re: GitHub Actions Pitfalls

#75

Post by hk1337 »

newman314 wrote: post #73

I generally like Actions but occasionally run into limitations (possibly my own). For example, I'd like to build an action that triggers a documentation update based on the path and filename that is changed. on: push: branches: - main paths: - */README.md But there does not appear to be a way to pass a list of changed paths to the job.

Maybe keep your documentation in a single directory?

  on:
    push:
      branches:
        - main
      paths:
        - docs/**
        - README.md
I use something similar for triggering different app workflows in a monorepo.

*EDIT* Or in multiple directories but grouped into multiple documentation directories.

  on:
    push:
      branches:
        - main
      paths:
        - package1/docs/**
        - package2/docs/**
        - package3/docs/**
        - README.md

Re: GitHub Actions Pitfalls

#76

Post by gabeio »

WirelessGigabit wrote: post #35

Dear GitHub actions. I want &pointers so I don’t have to repeat myself. Also, I like that you build the hypothetical merge of branch + main. But that commit SHA is gone after that successful build. Give me a way to track this. I need to store artifacts related to this build, as I don’t want to build those again!

> I need to store artifacts related to this build, as I don’t want to build those again!

https://docs.github.com/en/actions/using-workflows/storing-w...

they do seem to be capable of saving most things people call artifacts or if you are looking for something more along the lines of caching parts of the build for future builds, you can adjust it pretty easily by adjusting what the cache key is based on.

example:

  key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
which will allow you to cached based on the hash of a specific deps lock file instead of the commit sha.

https://docs.github.com/en/actions/using-workflows/caching-d...

https://github.com/actions/cache

The one note here is clearing that cache/cache management isn't straight forward currently (although they are improving it), there are a few acceptable workarounds though.

Not sure if you were aware of these already.

Re: GitHub Actions Pitfalls

#77

Post by hk1337 »

cmcconomy wrote: post #39

I now use a Makefile and put as much logic as I can in `make cicd` so I can call it in a single line, keeping the GitHub action as simple as possible.

Makefile or Ansible playlist, depending on what you're doing? Use Github Actions to prep the environment to run make or Ansible?

Re: GitHub Actions Pitfalls

#79

Post by thaeli »

0xbadcafebee wrote: post #43
cmcconomy wrote: post #39

I now use a Makefile and put as much logic as I can in `make cicd` so I can call it in a single line, keeping the GitHub action as simple as possible.

Absolutely. The problem is when you have a lot of time-consuming steps and you only want to re-run the failed one with a slight change and then continue where it left off. Make can do that of course, but you need to make Make do it, and save/restore a workspace/artifacts. I haven't done that in GHA and GHA has lacked a lot of core ci/cd functionality for a long time, so I don't know if it's possible in GHA.

Steps that only cache their final artifact on success, and an if condition on the skippable steps that only runs if the artifact doesn't exist. I'm using this to prevent re-running builds when a successful build for the same SHA already exists, for instance.

Re: GitHub Actions Pitfalls

#80

Post by ekimekim »

0xbadcafebee wrote: post #53
masklinn wrote: post #22

Earlier quoted context omitted.

You might be getting the string True because in Yaml 1.1 the scalars “y”, “n”, “yes”, “no”, “on”, and “off” (in all their casings) are Boolean literals. I believe YAML supports non-string keys, so your key would be parsed to the corresponding Boolean value (true), if the pipeline then goes through JSON where only string keys are supported the serialiser could simply stringing the key rather than raise an error, leadi…

I once worked on a project where the input was YAML config files and a lot of different programs would read/write the files. Every different parser had at least one implementation-specific quirk. Often we would run into the quirks because someone edited the YAML by hand, and one parser would handle it fine, while another would barf. That's when I found out the YAML spec explicitly says it's human- readable , not huma…

I've hit problems where YAML generated by one implementation will hit parsing quirks in another implementation. Now my advice is: If you have something that consumes YAML, generate JSON and feed it that instead. YAML is defined to be a superset of JSON, and every implementation should be able to handle it fine.

For those interested, the problem was with the string "08". At least at the time, the pyYAML generator I was using would render it as 08 (without quotes), which is not parsable as a number because the leading 0 indicates the number is in octal, but 8 isn't a valid octal digit. Since it wasn't parsable as a number, it should default to being treated as a string. However the golang parser disagreed and instead raised an error because "8" was not a valid octal digit.

Post reply on HN