28 ms·

If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions ot

If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`?

motorest 2y ago
> If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`? For you to make that comment, I'm not sure you ever went through any basic intro to GitHub Actions tutorial. GitHub Actions has 'run'. https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun https://docs.github.com/en/actions/writing-workflows/workflo... Now that we established that, GitHub Actions also supports custom actions, which is a way to create, share, and reuse high-level actions. Instead of copy-pasting stuff around, you do the equivalent of importing a third party module. https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions https://docs.github.com/en/actions/sharing-automations/creat... Onboarding a custom GitHub Action does not prevent you from using steps.run. I don't even know where to start regarding your comment on expression evaluation and conditions. Have you used a CICD system before? The problem with half the comments in this thread railing against CICD in general, YAML, etc is that they clearly do not have a faintest idea about what they are doing, and are instead complaining about ther own inability.
michaelmior 2y ago
I thin one big benefit of being able to do this is getting more visibility into the pipeline from the GitHub Actions UI/API (including status checks in PR builds). It also helps with reusability. If something is packaged as a GitHub Action, it's much easier to reuse than a shell script written for some other project. GitHub Actions is far from perfect, but I think once you get used to it, it works pretty well.

If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`?

motorest 2y ago

> If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`? For you to make that comment, I'm not sure you ever went through any basic intro to GitHub Actions tutorial. GitHub Actions has 'run'. https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun https://docs.github.com/en/actions/writing-workflows/workflo... Now that we established that, GitHub Actions also supports custom actions, which is a way to create, share, and reuse high-level actions. Instead of copy-pasting stuff around, you do the equivalent of importing a third party module. https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions https://docs.github.com/en/actions/sharing-automations/creat... Onboarding a custom GitHub Action does not prevent you from using steps.run. I don't even know where to start regarding your comment on expression evaluation and conditions. Have you used a CICD system before? The problem with half the comments in this thread railing against CICD in general, YAML, etc is that they clearly do not have a faintest idea about what they are doing, and are instead complaining about ther own inability.

michaelmior 2y ago

I thin one big benefit of being able to do this is getting more visibility into the pipeline from the GitHub Actions UI/API (including status checks in PR builds). It also helps with reusability. If something is packaged as a GitHub Action, it's much easier to reuse than a shell script written for some other project. GitHub Actions is far from perfect, but I think once you get used to it, it works pretty well.