Select build language and tooling

[deviantintegral]

If we don't use something that exists in #1 , we need to decide if we're using:

• PHP
• JavaScript
• Something else?

Along with some pre-existing job runner (like Robo, gulp, etc).

[justafish]

I don't think we can use just one language e.g. we're not going to run JavaScript/CSS builds using PHP, and we're not going to rewrite drush commands for updating the Drupal database in JavaScript. For some hosts we've also needed to run commands directly related to the filesystem/webserver (e.g. switching a symlink).

I'd like to go with something higher level for the task runner so it can interface easily with the likes of drush, gulp etc. I think https://taskfile.dev/ would work well for this because...

• It's a single Go binary with no dependencies so easy to install/ship with a project
• Support for environment variables and .env files
• Easy to follow syntax
• Allows overrides for different operating systems
• Things like Robo end up shelling out anyway, but now it's buried in PHP so it's hard to debug when something goes wrong (e.g. check the references to the taskExec and drush functions here https://github.com/acquia/blt/blob/main/src/Robo/Common/Executor.php)
• Allows includes in a similar manner to GitLab CI, which we can use to ship our build tools (in a composer package?) and allow the project to mix/match/override if needed, for example (I put task into vendor/bin for this example) -

Taskfile.yml

version: '3'

dotenv: ['.env']

includes:
  drupal: ./tasks/drupal.yml

tasks:
  default:
    cmds:
      - echo "Hello, world!"
      - 

tasks/drupal.yml

version: '3'

tasks:
  build:
    cmds:
      - composer install --no-dev
    # Test existence of files
    status:
      - test -f ./vendor/composer/installed.json
      - test -f ./vendor/composer/autoload.php
  update:
    cmds:
      - ./vendor/bin/drush {{.CLI_ARGS}} --yes cache:clear plugin
      - ./vendor/bin/drush {{.CLI_ARGS}} --yes updatedb --no-post-updates
      # Run config:import twice to make sure we catch any config that didn't declare
      # a dependency correctly. This is also useful when importing large config sets
      # as it can sometimes hit an out of memory error.
      - ./vendor/bin/drush {{.CLI_ARGS}} --yes config:import || true
      - ./vendor/bin/drush {{.CLI_ARGS}} --yes config:import
      - ./vendor/bin/drush {{.CLI_ARGS}} --yes updatedb --no-cache-clear
      - ./vendor/bin/drush {{.CLI_ARGS}} --yes cache:rebuild

One thing I really like about this is that using drush aliases you can reuse the task to run on a remote site and the syntax is pretty nice. It also avoids a vendor/platform specific tool e.g.

task drupal:update -- @pantheon.mysite.dev

or even wire it up to ddev -
.ddev/commands/web/task

#!/usr/bin/env bash

## Description: Run a Taskfile
## Usage: task <command>
## Example: "task drupal:update"

./vendor/bin/task $*

ddev task drupal:update -- @pantheon.drainpipe.dev

[deviantintegral]

That's wonderful! All your thoughts make sense to me. A few notes:

1. Do you have a sense as to how good it's validation of the Taskfile.yml is? Will it fail silently if you typo a key for example? Since it's in Go, I think it has to be good enough to debug without debugging the go code, since most of our team hasn't programmed in it.
2. "Task uses github.com/mvdan/sh, a native Go sh interpreter. So you can write sh/bash commands and it will work even on Windows, where sh or bash are usually not available. Just remember any executable called must be available by the OS or in PATH.": I think this makes sense, but are we opening ourselves up to tricky issues because it's not actually bash or sh? Full compatibility is hard. Perhaps this is just something we raise in our documentation as well.
3. To pin for later; I'd be curious if you can find any other Drupal peers using this, and if it's integrated in any other tools to help us towards closing Research existing templates and tools #1 .

[justafish]

1. There's a JSON schema that can be used for validation https://taskfile.dev/#/community?id=json-schema Add a process (or just document how) to validate a Taskfile #11
2. Thinking of the issues we've run into with e.g. sh on Ubuntu actually being dash - I think this is an awesome feature!
3. Not that I've come across with a cursory look