76 lines
4.9 KiB
YAML
76 lines
4.9 KiB
YAML
uuid:
|
|
- value: 27159a73-e3ac-4fa9-b18c-2f70157e31d7
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:53+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: 'run file vs task runners'
|
|
created:
|
|
- value: '2022-10-19T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:53+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2022/10/19/run-vs-task-runners
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p><a href="/daily/2022/08/15/using-run-file-simplify-project-tasks">I've written a few earlier emails</a> about <code>run</code> files - a simple bash file that I add to my projects to simplify or combine common commands that I need to run often.</p>
|
|
|
|
<p>Recently, I've looked at a couple of alternatives to see how they compare.</p>
|
|
|
|
<p>One is very YAML based where all commands are written within a YAML file, and one is very Makefile-like and it does fix some of the confusion and issues that I've made with Makefiles in the past - such as passing arguments to commands, and dealing with <code>.PHONY</code>.</p>
|
|
|
|
<p>Whilst I like both of these approaches and that they offer small additional features like auto-completion of task names, after using one of them in a project for a short while, I think that I'm going to stick with the <code>run</code> file.</p>
|
|
|
|
<p>The main reason for this is that I like the simplicity of the <code>run</code> file, and that it's just a Bash file that contains functions.</p>
|
|
|
|
<p>There were a couple of things that I couldn't quite get to work in one of the other tools, such as setting the TTY value in a Docker Command - which is something that I was able to do with bash within the <code>run</code> file. The fact that I can write regular bash and reuse existing knowledge is a big plus rather than having to try to learn another syntax or DSL for another tool.</p>
|
|
|
|
<p>The main reason though is because bash is already installed everywhere. There's no additional tool for Developers to download and install so it keeps the barrier to entry low, and there's no additional dependencies to add to my CI pipeline for it to work.</p>
|
|
|
|
<p>I was able to use one of these other tools in GitHub Actions as someone had already written a workflow for it, and although I could possibly install it via a package manager, just being able to run a bash file in any CI tool was probably the deciding factor to stick with <code>run</code> files.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p><a href="/daily/2022/08/15/using-run-file-simplify-project-tasks">I've written a few earlier emails</a> about <code>run</code> files - a simple bash file that I add to my projects to simplify or combine common commands that I need to run often.</p>
|
|
|
|
<p>Recently, I've looked at a couple of alternatives to see how they compare.</p>
|
|
|
|
<p>One is very YAML based where all commands are written within a YAML file, and one is very Makefile-like and it does fix some of the confusion and issues that I've made with Makefiles in the past - such as passing arguments to commands, and dealing with <code>.PHONY</code>.</p>
|
|
|
|
<p>Whilst I like both of these approaches and that they offer small additional features like auto-completion of task names, after using one of them in a project for a short while, I think that I'm going to stick with the <code>run</code> file.</p>
|
|
|
|
<p>The main reason for this is that I like the simplicity of the <code>run</code> file, and that it's just a Bash file that contains functions.</p>
|
|
|
|
<p>There were a couple of things that I couldn't quite get to work in one of the other tools, such as setting the TTY value in a Docker Command - which is something that I was able to do with bash within the <code>run</code> file. The fact that I can write regular bash and reuse existing knowledge is a big plus rather than having to try to learn another syntax or DSL for another tool.</p>
|
|
|
|
<p>The main reason though is because bash is already installed everywhere. There's no additional tool for Developers to download and install so it keeps the barrier to entry low, and there's no additional dependencies to add to my CI pipeline for it to work.</p>
|
|
|
|
<p>I was able to use one of these other tools in GitHub Actions as someone had already written a workflow for it, and although I could possibly install it via a package manager, just being able to run a bash file in any CI tool was probably the deciding factor to stick with <code>run</code> files.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|