by mariusandra on 8/19/21, 2:12 PM with 70 comments
by duped on 8/19/21, 3:53 PM
It's cost me hundreds to thousands of dollars to implement nontrivial workflows because of how the YAML is parsed (for example, empty strings when using a secret that has been renamed or removed) and the lack of introspection or debuggability when something goes wrong.
It's gotten to the point where new any new workflows I write are thin wrappers around a single script and I don't import any actions besides actions/checkout (even that has been bug prone, historically).
All that said, it's not like other platforms are better. But they certainly are cheaper and don't have dumb breakages when you need cross platform builds (has upload-artifact been fixed for executables on MacOS yet?)
by danpalmer on 8/19/21, 2:50 PM
On that last one, there's a potential bug in the deployment pipeline here – deploys could run simultaneously or some bad luck on runner speed could even see an older version of the code go out after a newer version. Combined with the automated database migrations this could be quite a big problem!
Actions thankfully solved this recently with the `concurrency` key that lets you form a serial queue by a given key such as the branch name.
by BugsJustFindMe on 8/19/21, 3:25 PM
Like...the last time I checked, workflows had no runtime macro for limiting execution to the default branch except explicitly by a specific name, and the closest you could get to generically checking "whatever the default branch is called right now" was either a template workflow that would set some static text for the name at creation that breaks if the default branch name is subsequently changed or a song and dance querying the API and setting an environment variable inside one of the workflow steps and then gating all subsequent steps on the result. This was a long time after they introduced editable default branch names and seems like such an obvious oversight.
Then there are weird quirks like the subshell file system permissions block that requires using sudo if you want to move files around within your repo clone from inside an invoked shell script.
by crooked-v on 8/19/21, 9:08 PM
- You can't pull in private dependencies published from other repos (for example, packages published on repo A used as a dependency on repo B) without using a private access token.
- You can't use git pulls from other repos (for example, repo B using `orgname/repoA#123456` as a dependency in package.json) without using a private access token, and it's a pain in the ass to make it work across workflow steps.
- You can't allow Dependabot to run as a trusted user, which makes it impossible to actually use any of the workarounds for the above issues with it.
- You can't create PRs to publish changes across repos (such as automatically keeping some set of files in sync) without using a private access token.
There are other complications, but those are the biggest ones.
by reidjs on 8/19/21, 3:14 PM
by bklyn11201 on 8/19/21, 3:55 PM
by valenterry on 8/20/21, 12:40 AM
by cube00 on 8/20/21, 2:21 AM
For example, recently when they had to reduce access to GitHub Actions because miners were abusing it.
Where as my local configuration management (Ansible, Puppet etc.) script can always run anywhere and I can even run on my own build VM if I need too.
by c17r on 8/19/21, 4:31 PM
by jbergstroem on 8/19/21, 7:01 PM
by atonse on 8/19/21, 9:51 PM
Does GitLab have a response planned?
by AliBoukeroui on 8/20/21, 12:20 AM
by ryanmarsh on 8/19/21, 2:41 PM