zlacker

[parent] [thread] 12 comments
1. JMTQp8+(OP)[view] [source] 2020-04-14 16:37:38
I'd like to share feedback on GitHub Actions. Tried it out, and the learning curve was too much. I want to use stuff I already know -- e.g., write a Dockerfile, and then GH could run it on PR builds. The "workflow" concept didn't land for me, and I hope you consider a more generalized, open-source approach to running arbitrary scripts in response to PRs being opened, merges to master, etc.
replies(5): >>edaemo+j8 >>jeremy+Qe >>armads+lf >>tracke+uR >>Ayesh+pg1
2. edaemo+j8[view] [source] 2020-04-14 17:14:03
>>JMTQp8+(OP)
Have you tried other CI/CD platforms? Different providers use different language but the workflow concept underpins all CI/CD pipelines.
replies(1): >>JMTQp8+0h
3. jeremy+Qe[view] [source] 2020-04-14 17:44:01
>>JMTQp8+(OP)
They opened sourced the runner[0] if you're interested in learning how it works. Understanding the internals of it may or may not help the syntax and concepts of Actions land though.

My guess is that it is unlikely to see your request for a more generalized script or Dockerfile runner realized because that (Dockerfiles) was the original implementation of Actions during the beta; they pivoted away from that to the current form.

[0] - https://github.com/actions/runner

4. armads+lf[view] [source] 2020-04-14 17:46:25
>>JMTQp8+(OP)
Counterpoint: I've never used Docker at all (I'm a Mac/iOS dev), and was able to get GitHub actions set up and doing what I needed it to in ~30 minutes. Its general similarity to other CI/CD solutions, TravisCI being the one I'm most familiar with, helped a lot.
replies(1): >>techni+2M
◧◩
5. JMTQp8+0h[view] [source] [discussion] 2020-04-14 17:52:31
>>edaemo+j8
My team stuck with Jenkins, Docker, and custom shell scripts to get the job done.
◧◩
6. techni+2M[view] [source] [discussion] 2020-04-14 20:27:00
>>armads+lf
As an ios dev too, do you have any favorite actions you can recommend?
7. tracke+uR[view] [source] 2020-04-14 21:00:10
>>JMTQp8+(OP)
I don't think it was particularly difficult to use... the multi-os targets are probably about the most confusing.

I tend to stick with bare scripts and npm scripts as much as possible though, so the environment doesn't matter as much.

replies(1): >>JMTQp8+gW
◧◩
8. JMTQp8+gW[view] [source] [discussion] 2020-04-14 21:26:49
>>tracke+uR
The YAML configuration is something I have to learn that provides no value-add outside of GitHub. If it was at least based on Docker, you could re-use existing technical knowledge or teach people something that's valuable in other contexts.
replies(1): >>tracke+T21
◧◩◪
9. tracke+T21[view] [source] [discussion] 2020-04-14 22:07:39
>>JMTQp8+gW
A lot of things use YAML for configuration... what would you prefer for configuration? XML?
replies(2): >>JMTQp8+wb1 >>dserod+Lco
◧◩◪◨
10. JMTQp8+wb1[view] [source] [discussion] 2020-04-14 23:16:00
>>tracke+T21
I want to write a Dockerfile. I don't particularly have an issue with YAML.
replies(1): >>tracke+6h1
11. Ayesh+pg1[view] [source] 2020-04-14 23:58:39
>>JMTQp8+(OP)
Coming from Travis CI and GitLab CI, GitHub Actions was very intuitive and I had it running in the very first take.

The concept of actions is new, but it is brilliant compared to traditional approach of doing everything inside the CI jobs, or bring your own docker images.

◧◩◪◨⬒
12. tracke+6h1[view] [source] [discussion] 2020-04-15 00:06:10
>>JMTQp8+wb1
then why not write a dockerfile, and have your yaml, just do the docker build... command?
◧◩◪◨
13. dserod+Lco[view] [source] [discussion] 2020-04-23 20:43:36
>>tracke+T21
HCL, which is what GitHub Actions used when it first launched
[go to top]