If you want to run github actions locally before any pitfalls, you can try out https://github.com/nektos/act
That's pretty cool. I could have used something like that for Microsoft's CI.
GitHub Actions Pitfalls
21–30 of 111 posts
Re: GitHub Actions Pitfalls
#22Also a fun one is the "on" key that specifies when the workflow should run. "on" is magic in yaml, and some implementations will convert it to the string (!) "True" when it occurs as a key (I'm not talking about values here). This was a bit confusing when I tried to replace a hand-written yaml with a generated json ... They were identical, except for the on/True key. It's still not clear to me whether this is accordi…
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, leading to “True”.
And that’s one of the billion reasons why barewords are bad.
I think this has been fixed in Yaml 1.2, but there’s a lot of Yaml 1.1 libraries out there, and they can’t just switch since they could break user code.
Re: GitHub Actions Pitfalls
#23If you want to run github actions locally before any pitfalls, you can try out https://github.com/nektos/act
[deleted]
Re: GitHub Actions Pitfalls
#24I 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.
No post body was provided.
Re: GitHub Actions Pitfalls
#25Another pitfall I ran into recently with a workflow I've been working on [1]: Checks and CI that are made with GitHub Actions are reported to the new Checks API, while some (all?) external services report to their old Statuses API. This makes it needlessly difficult to ascertain whether a PR/branch is "green" or not. They finally decided to create a "statusRollUp" that combines the state of the two APIs, but it's not available in their REST api, only their GraphQL API.
Re: GitHub Actions Pitfalls
#26Also a fun one is the "on" key that specifies when the workflow should run. "on" is magic in yaml, and some implementations will convert it to the string (!) "True" when it occurs as a key (I'm not talking about values here). This was a bit confusing when I tried to replace a hand-written yaml with a generated json ... They were identical, except for the on/True key. It's still not clear to me whether this is accordi…
I wrap on in quotes since my syntax highlighter translates it to a bool. You can quote keys in YAML without issue, but it does look a little strange.
Re: GitHub Actions Pitfalls
#27Oh, there's many more. For example: the cache action is lacking restore-only options, and there's no explicit step to fail a workflow.
Re: GitHub Actions Pitfalls
#28I 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.
I've been waiting since 2013 for crypto to have a facebook-level contribution but it's still just the same crap. Every 2-3 years, the world remembers crypto exists and they funnel money into it only to be fleeced. I've yet to see one piece of tech from the crypto craze that has substantially altered peoples' lives besides losing most people money.
If you're looking to get on the jump for a new piece of tech, it's probably too late for crypto anyways. My mom knows about it. lol
Re: GitHub Actions Pitfalls
#29Re: GitHub Actions Pitfalls
#30Their self-hosted runners are pretty jank. If your workflow writes something to the docker container's user's home directory, you will see it in the next workflow you run. Due to this and other things, I need a "preamble" action that needs to run right after checkout. Oh, if don't checkout at the beginning of your workflow, you will be using the previous workflow's copy of the repository.
I'm 100% sure they don't use this internally as these are glaring issues that impacts anyone using the self hosted runner. They also recommend running the container as root[1] instead of designing something more secure and sane.
1: https://github.com/actions/runner/issues/434#issuecomment-61...