Taskfile.yml.liquid

---
version: '3'

output: interleaved

vars:
  DOCKERHUB_PROFILE:
    sh: |
      if [ -f .config/variables.json ] && type jq &> /dev/null; then
        echo "$(jq -r '.profile.dockerhub' .config/variables.json)"
      else
        echo 'megabytelabs'
      fi
  DOCKERHUB_USER:
    sh: |
      if [ -f .config/variables.json ] && type jq &> /dev/null; then
        echo "$(jq -r '.profile.dockerHubUser' .config/variables.json)"
      else
        echo 'ProfessorManhattan'
      fi
  ESLINT_FIX_RECURSIVE: 'true'
  ESLINT_FORMATTER: stylish
  ESLINT_FORMATTER_OPTIONS: git-log gitlab pretty summary
  GALAXY_AUTHOR: ProfessorManhattan
  GALAXY_COMPANY: Megabyte Labs
  GALAXY_NAMESPACE:
    sh: |
      if [ -f meta/main.yml ]; then
        grep namespace < meta/main.yml | sed 's/.*namespace: \\(.*\\)$/\\1/g'
      else
        if [ -f .config/variables.json ] && type jq &> /dev/null; then
          echo "$(jq -r '.profile.galaxy' .config/variables.json)"
        else
          echo 'ProfessorManhattan'
        fi
      fi
  GALAXY_ROLE_NAME:
    sh: "if [ -f meta/main.yml ]; then grep role_name < meta/main.yml | sed 's/.*role_name: \\(.*\\)$/\\1/g'; fi"
  GITHUB_ORG:
    sh: |
      if [ -f package.json ] && type jq &> /dev/null && [ "$(jq -r '.blueprint.repository.github' package.json)" != 'null' ]; then
        echo "$(jq -r '.blueprint.repository.github' package.json | sed 's/https:\/\/github.com\///' | sed 's/\/.*$//')"
      elif [ -f .config/variables.json ] && type jq &> /dev/null; then
         echo "$(jq -r '.profile.githubOrg' .config/variables.json)"
      else
        echo 'megabyte-labs'
      fi
  GITHUB_USER:
    sh: |
      if [ -f .config/variables.json ] && type jq &> /dev/null; then
         echo "$(jq -r '.profile.github' .config/variables.json)"
      else
        echo 'ProfessorManhattan'
      fi
  GROUP_EXEC_ASYNC: 'false'
  # yamllint disable rule:line-length
  IGNORE_FOLDERS: >-
    -path './.autodoc/*' -o -path './.cache/*' -o -path './.common*' -o -path './.config/*' -o -path './.git/*' -o
    -path './.modules/*' -o -path './.npm/*' -o
    -path './.pnpm-store/*' -o -path './.shared/*' -o -path './.task/*' -o -path './.venv/*' -o -path './.vscode/*' -o
    -path './build/*' -o -path './dist/*' -o -path './node_modules/*' -o -path './roles/*' -o -name pnpm-lock.yaml -o
    -name package-lock.json -o -name poetry.lock -o -name '.variables.json' -o -name '.git'
  INIT_SCRIPT: https://gitlab.com/megabyte-labs/gitlab-ci/-/raw/master/scripts/update-init.sh
  LOG_FIX:
    sh: chmod +x .config/log
  MODEL_TASKFILE: https://gitlab.com/megabyte-labs/common/shared/-/raw/master/Taskfile.yml
  NPM_KEEP_UPDATED: ''
  NPM_PROGRAM: pnpm
  PROJECT_TYPE:
    sh: |
      if type jq &> /dev/null && [ -f package.json ]; then VER="$(jq -r '.blueprint.group' package.json)"; if [ "$VER" == 'null' ]; then TYPE="$GROUP_TYPE"; else TYPE="$VER"; fi; else TYPE="$GROUP_TYPE"; fi
      if type jq &> /dev/null && [ -f package.json ]; then VER="$(jq -r '.blueprint.subgroup' package.json)"; if [ "$VER" == 'null' ]; then SUBTYPE="$REPOSITORY_TYPE"; else SUBTYPE="$VER"; fi; else SUBTYPE="$REPOSITORY_TYPE"; fi
      if [ "$TYPE" == 'common' ] && [ "$SUBTYPE" == 'shared' ]; then
        echo 'shared'
      elif [ "$TYPE" == 'common' ]; then
        echo 'common'
      elif [ "$TYPE" == 'documentation' ] && [ "$SUBTYPE" == 'shared' ]; then
        echo 'commondocs'
      elif [ "$TYPE" == 'documentation' ]; then
        echo 'docs'
      else
        echo 'project'
      fi
  # yamllint enable rule:line-length
  PYTHON_HANDLE:
    sh: |
      if type poetry &> /dev/null; then
        echo 'poetry run '
      else
        echo ''
      fi
  PYTHON_VIRTUALENV: true
  REPOSITORY_SUBTYPE:
    sh: |
      if [ -n "$REPOSITORY_TYPE" ]; then REPO_SUBTYPE="$REPOSITORY_TYPE"; fi
      if type jq &> /dev/null && [ -f package.json ]; then
        VER="$(jq -r '.blueprint.subgroup' package.json)"
        if [ "$VER" == 'null' ]; then
          if [ -n "$REPO_SUBTYPE" ]; then echo "$REPO_SUBTYPE"; else echo "misc"; fi
        else
          echo "$VER"
        fi
      else
        if [ -n "$REPO_SUBTYPE" ]; then echo "$REPO_SUBTYPE"; else echo "misc"; fi
      fi
  REPOSITORY_TYPE:
    sh: |
      if [ -n "$GROUP_TYPE" ]; then REPO_TYPE="$GROUP_TYPE"; fi
      if type jq &> /dev/null && [ -f package.json ]; then
        VER="$(jq -r '.blueprint.group' package.json)"
        if [ "$VER" == 'null' ]; then
          if [ -n "$REPO_TYPE" ]; then echo "$REPO_TYPE"; else echo "misc"; fi
        else
          echo "$VER"
        fi
      else
        if [ -n "$REPO_TYPE" ]; then echo "$REPO_TYPE"; else echo "misc"; fi
      fi
  SEMANTIC_CONFIG: semantic-release-config
  TIMEZONE: America/New_York

env:
  GOPATH:
    sh: |
      if [ -z "$GOPATH" ]; then
        echo "$HOME/.local/go"
      else
        echo "$GOPATH"
      fi
  OSTYPE:
    sh: |
      \{{if (eq OS "linux")}}LINUX_FLAVOR='linux-gnu'
      LIBC=$(ldd /bin/ls | grep 'musl' | head -1 | cut -d ' ' -f1)
      if [ -n "$LIBC" ]; then LINUX_FLAVOR='linux-musl'; fi\{{end}}
      echo "\{{if (eq OS "linux")}}$LINUX_FLAVOR\{{else}}darwin\{{end}}"
  PATH:
    sh: |
      PATH="$PATH:$HOME/.local/bin:$HOME/.poetry/bin:$HOME/.gem/bin:$HOME/.asdf/bin"
      PATH="$PATH:$HOME/.local/go/bin:$HOME/go/bin"
      PATH="$PATH:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin"
      PATH="$PATH:$PWD/bin"
      PATH="$PATH:$HOME/.volta/bin"
      echo "$PATH"
  RECORD_INSTALL:
    sh: if [ -n "$CI" ]; then echo 'true'; fi
  SENTRY_DSN:
    sh: |
      if type jq &> /dev/null; then
        DSN="$(jq -r '.blueprint.sentryDSN' package.json)"
        if [ "$DSN" != 'null' ]; then echo "$DSN"; fi
      fi
  VOLTA_HOME:
    sh: echo "$HOME/.volta"

includes:
{{#forEach (bodegaIncludes)}}
  {{key}}:
    taskfile: {{taskPath}}
    optional: true
{{/forEach}}

profile: |
  if [[ "$OSTYPE" == 'linux-gnu'* ]] || [[ "$OSTYPE" == 'linux-musl'* ]]; then
    if [ -f /home/linuxbrew/.linuxbrew/bin/brew ] && ! type brew > /dev/null; then
      eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
    fi
  fi
  if [[ "$OSTYPE" == 'darwin'* ]] && type brew > /dev/null; then
    BREW_PREFIX="$(brew --prefix)"
    PATH="$PATH:$BREW_PREFIX/opt/coreutils/libexec/gnubin"
    PATH="$PATH:$BREW_PREFIX/opt/findutils/libexec/gnubin"
    PATH="$PATH:$BREW_PREFIX/opt/gnu-sed/libexec/gnubin"
    PATH="$PATH:$BREW_PREFIX/opt/grep/libexec/gnubin"
    PATH="$PATH:$BREW_PREFIX/opt/gnu-tar/libexec/gnubin"
    PATH="$PATH:$BREW_PREFIX/opt/gawk/libexec/gnubin"
  fi
  if [ -f .venv/bin/activate ]; then
    . .venv/bin/activate
  fi

tasks:
  build:
    deps:
      - install:software:jq
      - install:software:node
    desc: Build the project using the build script defined in `package.json`
    vars:
      NONINTERACTIVE_MISSING_BUILD_CMD: There must be a build command under `.scripts.build` in `package.json`!
    summary: |
      # Build the Project

      Use this command to build the project. It executes the command defined
      in `package.json` under the `.scripts.build` key.
    log:
      start: Running `npm run build`
      success: Successfully ran `npm run build`
      error: Encountered error while running `npm run build`
    cmds:
      - |
        if [ "$(jq '.scripts.build' package.json)" != 'null' ]; then
          if type npm &> /dev/null; then
            npm run build
          else
            task \{{.REPOSITORY_TYPE}}:build
          fi
        else
          [[ $- == *i* ]] && task prepare || (.config/log error '\{{.NONINTERACTIVE_MISSING_BUILD_CMD}}' && exit 1)
        fi

  clean:
    desc: Removes optional folders that are cached during various tasks
    summary: |
      # Clean Project / Remove Optional Directories and Files

      This task will remove all the unnecessary files that are downloaded, generated, and
      cached during various build steps. This task is used by the `reset` task
      which will re-generate the project from scratch. Ideally, this task and the reset task
      should never be necessary. The `start` task should be used instead.
    vars:
      CLEAN_TARGETS: .autodoc .cache .task .venv node_modules tsconfig.tsbuildinfo venv
        .variables.json
    cmds:
      - task: common:clean
        vars:
          CLEAN_TARGETS: '\{{.CLEAN_TARGETS}}'

  commit:
    desc: Lint staged files, report spelling errors, and open a _required_ commit dialoge
    summary: |
      # Commit Code

      This task will perform linting and auto-fixing on the files that have been staged in
      git (i.e. the files that were added with `git add --all`). It will then report possible
      spelling errors that you may choose to fix. Then, it opens a _required_ interactive commit
      questionnaire that will help you make better commits that are compatible with software
      that generates the CHANGELOG.md.

      It is very important that you use this task to commit rather than the conventional approach
      using `git commit -m`. However, if you really need to, you can add the flag `--no-verify`
      to your regular `git commit -m` command to bypass the pre-commit hook.
    cmds:
      - task: common:commit

  commit:all:
    deps:
      - install:software:git
    desc: Add all the untracked changes and commit the code
    summary: |
      # Commit All Untracked Code

      By default, this task is an alias for:

      ```
      git add --all
      git commit
      ```

      If you pass a commit message as a CLI argument, then the pre-commit
      logic will be bypassed. By bypassing the hooks, the commit message will be
      excluded from the automatic CHANGELOG.md entry generated during commits.
      Passing the commit message as a CLI argument can be done like so:

      ```
      task commit -- "Added new files that do not need to show up in CHANGELOG.md"
      ```
    log:
      start: Adding all changes and committing
      success: Successfully commit changes
      error: Error while running commit logic
    cmds:
      - |
        \{{if .CLI_ARGS}}
        task --list > /dev/null || (echo "ERROR: Invalid Taskfiles!" && exit 1)
        git add --all
        HUSKY=0 git commit -m "\{{.CLI_ARGS}}" --no-verify
        \{{else}}
        task --list > /dev/null || (echo "ERROR: Invalid Taskfiles!" && exit 1)
        git add --all
        git commit
        \{{end}}

  commit:quick:
    deps:
      - ci:commit:config
    cmds:
      - |
        task --list > /dev/null || (echo "ERROR: Invalid Taskfiles!" && exit 1)
        git add --all
      - HUSKY=0 git commit -m '🔧 chore(tweak): quick minor update' --no-verify
      - git push origin master

  devcontainer:
    deps:
      - install:npm:devcontainer
      - install:software:docker

  donothing: 'true'

{{#eq group "ansible"}}{{#eq subgroup "playbook"}}
  environment:
    interactive: true
    desc: Symlink to an environment in the `environments/` folder
    summary: |
      # Switch Environments Using an Interactive Dialogue

      Ansible does not really provide any great ways to switch between environments (or sets of
      `host_vars/`, `group_vars/` etc.). If you place all the files and folders you wish to constitute
      as an environment inside a folder named as the name of the environment in the `environments/` folder
      then you can use this task to handle the symlinking and switching between environments.

      **Example of opening the interactive prompt:**
      `task ansible:environment`

      **You can directly switch enironments to `environments/prod/` by running:**
      `task ansible:environment -- prod`
    cmds:
      - task: ansible:playbook:environment
    build: |
      yq eval -i -P '.tasks.environment.summary = $summary' .config/taskfiles/ansible/Taskfile.yml
{{/eq}}{{/eq}}
  fix:
    desc: Run code auto-fixers / auto-formatters
    summary: |
      # Auto-Fix / Auto-Format Code

      This task will automatically apply lint fixes across the whole project using
      auto-fixers. Although unlikely, it is possible that auto-fixing can introduce
      an error so the auto-fixes still have to be validated.
    cmds:
      - task: fix:all

  fresh:
    summary: Initialize a new project with only the Taskfile.yml present
    cmds:
      - curl -sSL https://gitlab.com/megabyte-labs/common/shared/-/raw/master/common/start.sh > start.sh
      - curl -sSL https://gitlab.com/megabyte-labs/common/shared/-/blob/master/common/.gitignore > .gitignore
      - curl -sSL https://gitlab.com/megabyte-labs/common/shared/-/blob/master/common/.editorconfig > .editorconfig
      - curl -sSL https://gitlab.com/megabyte-labs/common/shared/-/blob/master/package.json > package.json
      - curl -sSL https://gitlab.com/megabyte-labs/common/shared/-/blob/master/.gitlab-ci.yml > .gitlab-ci.yml
      - TMP="$(mktemp)" && jq -r 'del(.blueprint)' package.json > "$TMP" && mv "$TMP" package.json
      - bash start.sh
      - task: prepare

  get:links:
    deps:
      - install:software:jq
    desc: Log useful links such as the current project's git repository link
    vars:
      GITHUB_URL:
        sh: jq -r '.blueprint.repository.github' package.json
      GITLAB_URL:
        sh: jq -r '.blueprint.repository.gitlab' package.json
    cmds:
      - .config/log info 'GitHub -----> `\{{.GITHUB_URL}}`'
      - .config/log info 'GitLab -----> `\{{.GITLAB_URL}}`'

  group:exec:
    desc: Execute group commands on any GitLab group (including repositories in sub-groups)
    summary: |
      # Run Commands on Multiple GitLab Repositories

      This command requires that the `GITLAB_TOKEN` environment variable be set. With the
      token defined, you can use this task to run scripts on repositories that fall under
      any given group or sub-group. By default, it runs the script(s) on all the
      repositories in the specified group and sub-groups.

      You can use this task to perform adhoc bulk changes to large numbers of
      repositories that are hosted on GitLab.

      **Example usage:**
      `task group:exec -- group/subgroup ---- 'bash <(curl https://myscript.com)'

      In the example above, the bash command will be run in the root of each repository.
      Be sure to wrap the command in quotes or you might observe some odd behavior.
    cmds:
      - task: git:gitlab:group:exec

  ssh-keys:
    deps:
      - cloud:heroku:ssh-keys
      - git:github:ssh-keys
      - git:gitlab:ssh-keys

  init:
    deps:
      - install:software:jq
      - install:software:yq
    desc: Runs the initialization script
    summary: |
      # Initialize the Project

      This command will mostly not be needed for pre-existing projects. This task:

      1. Migrates legacy projects
      2. Fixes common errors
      3. Ensures the project is initialized
      4. Prompts for missing metadata
      5. Runs the `start` task

      If you are facing difficulties, you can try running this task to reset the project,
      perform common fixes, and run the whole start up routine.

      ## Using a Custom Initialization Script

      You can control the initialization script that this task runs by specifying
      `UPDATE_INIT_SCRIPT` as an environment variable. If it is not specified, then this
      task runs the [default script](\{{.INIT_SCRIPT}}).
    log:
      start: Initializing project by running initialization script
      success: Successfully bootstrapped project by running initialization script
      error: Failed to run initialization script
    cmds:
      - git init
      - task: repair
      - task: prepare

  jumpusb:
    desc: Creates a JumpUSB (https://jumpusb.com)
    cmds:
      - task: install:ventoy

  lint:
    desc: Lints the project using all linters
    summary: |
      # Lint the Project Using Most of the Linters

      This task will do a project-wide linting using all of the linters that commonly
      report errors. You can use this task to spot linting errors prior to running
      the git pre-commit hooks.

      **Example usage:**
      `task lint`
    cmds:
      - task: lint:all

  livereload:
    deps:
      - install:npm:nodemon
    desc: Start the project with live-reloading (i.e. watch mode)
    summary: |
      # LiveReload the Project

      Using LiveReload, you can automatically run the project any time you make
      changes to the project. The LiveReload feature uses [nodemon](https://github.com/remy/nodemon)
      with the configuration stored in `.config/nodemon.json`.

      Whenever you make a change to the project, `task project:livereload` will run. You can
      define the command that runs every time you make a change in the `Taskfile-project.yml`
      `livereload` section. This file is kept intact even across upstream propagation updates,
      unlike the regular `Taskfile.yml`.

      **Example usage:**
      `task livereload`

      The default configuration (in `.config/nodemon.json`) is generic and makes assumptions
      about the file types to watch based on what type project it is. If you would like to
      use a different configuration, you can pass in the location of the configuration like so:

      **Example with custom configuration:**
      `task livereload -- nodemon.custom.json`

      The task program also provides a `--watch` feature. However, it relies on the `sources` attribute
      being defined so it might not work in all cases.

      **Example using `task --watch`:**
      `task --watch mytask`
    log:
      start: Starting `nodemon` live-reload session
    cmds:
      - |
        if [ ! -f Taskfile-project.yml ]; then
          .config/log error '`Taskfile-project.yml` must exist and have a `livereload` task to use with `nodemon`' && exit 1
        fi
      - nodemon --config \{{if .CLI_ARGS}}\{{.CLI_ARGS}}\{{else}}.config/nodemon.json\{{end}}

  new:project:
    desc: Create a new project
    cmds:
      - task: prepare

  publish:
    desc: Publish a semantic release via `semantic-release`
    summary: |
      # Publish the Project

      Using this task, you can publish a project to all its targets. The targets
      depend on the project type. Most projects will include:

      1. Updating version numbers in `package.json`, `pyproject.toml`, etc.
      2. Adding a new git tag at the version and publishing it with updated assets
      3. Publishing repository-specific items like NPM packages, PyPi packages, etc.
      4. Publishing artifacts to GitLab Releases and GitHub Releases
      5. Updating the `docs/CHANGELOG.md`

      ## Packages Used

      This task runs `semantic-release` using the `semantic-release-config` package. The package
      includes release instructions for:

      1. Python packages
      2. NPM packages
      3. Dockerfile projects
      4. Go projects
      5. Ansible roles

      ## Formats

      It does its best to ship projects out in as many formats (that make sense) as possible.
      For instance, an NPM CLI gets published as:

      1. NPM package
      2. Binaries (including deb and rpm) available on GitHub/GitLab releases
      3. Brew formulae
      4. Snapcraft
      5. Probably more implemented after writing this

      ## Python Package Notes

      If `setup.cfg` is present, then the project is assumed to be a legacy Python
      project that needs to run in environment with access to the `python-semantic`
      extras defined in `pyproject.toml`.
    log:
      error: Error running `semantic-release` via `task publish`
      start: Running `semantic-release` via `task publish`
      success: Successfully ran `semantic-release` via `task publish`
    cmds:
      - task: publish:semantic-release

  publish:force:
    vars:
      UPDATE_LEVEL: '\{{if .CLI_ARGS}}\{{.CLI_ARGS}}\{{else}}PATCH UPDATE\{{end}}'
    desc: Force a `semantic-release` even if there are no new eligible commits
    summary: |
      # Force a Release with Empty Commit

      Trigger any kind of version bump / semantic release by passing
      `PATCH UPDATE`, `MINOR UPDATE`, or `MAJOR UPDATE` in via CLI arguments.
      This task will commit an empty commit message that will trigger the
      corresponding version bump type.

      **Example of patch update:**
      `task publish:force -- 'PATCH UPDATE'`

      **Example of minor update:**
      `task publish:force -- 'MINOR UPDATE'`

      **Example of major update:**
      `task publish:force -- 'MAJOR UPDATE'`
    log:
      error: Error creating update via `task publish:force`
      start: Publishing `semantic-release` update via `task publish:force`
      success: Successfully published update via `task publish:force`
    cmds:
      - |
        HUSKY=0 git commit -a --allow-empty -m '🔨 chore(bump): Forced semantic-release \{{.UPDATE_LEVEL}}' -n
      - task: publish
{{#eq group 'ansible'}}{{#eq subgroup 'playbook'}}
  playbook:
    desc: Run the playbook
    summary: |
      # Run the Playbook

      This task will prompt you for the environment and inventory you would like to
      run the `main.yml` playbook with. It will:

      1. Symlink all roles in the `roles/` folder to `~/.ansible/roles`
      2. Run `task environment` (which prompts and symlinks the appropriate environment)
      3. Prompt for which inventory to use
      4. Run `ansible-playbook -i inventories/your_choice --ask-vault-pass main.yml`

      **Example usage:**
      `task playbook`

      **Example bypassing prompts, using the `inventories/inventory.yml` file:**
      `task playbook -- inventory.yml`
    cmds:
      - task: ansible:playbook:run

{{/eq}}{{/eq}}
  preload:
    desc: Set up your workstation in advance by installing commonly used programs
    summary: |
      # Speed Up Future Development by Preloading Common System Applications

      Just about every development task requires some sort of globally installed
      application. TypeScript requires Node.js to be installed. Ansible requires
      a handful of CLIs (and Python). This task will check for missing applications
      and install them globally. If you do not run this task, the routines will
      assume you want to keep the footprint small and use disposable virtual
      environments whenever possible (i.e. `\{{.NPX_PACKAGE}}` in the case of Node.js,
      `poetry` in the case of Python, etc.).

      ## Reboot Requirements

      Some software that is installed, like VirtualBox and Docker, require reboots so
      it is recommended that you reboot after running this task.

      ## Passwordless Installation

      This installation method and all the methods we use will only prompt for a sudo
      password when absolutely necessary. If you already have common development tools
      it is possible that you will not even have to enter a sudo password. This is
      accomplished by installing to `$HOME/.local/bin` whenever a traditionally system
      level binary is installed. However, if you are missing something like git, then
      chances are you will be asked for a sudo password. In this case, we recommend
      you adopt the Megabyte Labs philosophy and inspect the code before running it.
    log:
      start: Preloading system with common dependencies
      success: Successfully preloaded system with common dependencies (REBOOT RECOMMENDED)
      error: Encountered error while preloading system with common dependencies (REBOOT RECOMMENDED)
    cmds:
      - task: install:software:common
      - task: install:brewfile
      - task: install:extras
      - task: install:go:bundle
      - task: install:rust:bundle
      - task: install:github:bundle
      - task: install:npm:bundle
      - task: install:pipx:bundle
      - task: install:python:requirements
      - task: install:modules:local

  prepare:
    desc: Prepares the project for the normal start command
    summary: |
      # Prepare the Project

      This task ensures the project has all the required metadata. If a project
      is missing required metadata then this task will interactively prompt the user
      for the missing data. It also performs miscellaneous tasks that are sometimes
      required by the `start` task.
    log:
      start: Preparing the project
      success: Successfully prepared the project
      error: Encountered error while preparing the project
    cmds:
      - task: boilerplate:check:package
      - task: boilerplate:clean

  repair:
    cmds:
      - task: common:repair
      - |
        TMP="$(mktemp)"
        if [ -n "$UPDATE_INIT_SCRIPT" ]; then
          curl -sSL "$UPDATE_INIT_SCRIPT" > "$TMP" && bash "$TMP" && rm "$TMP"
        else
          curl -sSL \{{.INIT_SCRIPT}} > "$TMP" && bash "$TMP" && rm "$TMP"
        fi

  reset:
    desc: Resets the project by removing all caches and then re-generating templated files
    summary: |
      # Reset Project and Re-Generate Assets

      This task is intended to be used when there appear to be cache related issues.
      It will first clean the project by removing common local libraries like `node_modules/`
      and the `.cache/` folder, to name a couple. Then, without acquiring any upstream
      updates, it re-generates any templated files.
    cmds:
      - task: common:reset

  pull:upstream:
    desc: Pull from upstream repositories
    summary: |
      # Pull Changes from Upstream Repositories

      This task will do a `git pull` on each repository defined in `.blueprint.upstreamRemotes`.
      The variable should be an array of objects where each object has the `remote`, `url`, and `branch` keys.

      **Sample value of `.blueprint.upstreamRemotes`:**
      `[{ "remote": "ionic", "url": "git@github.com:ionic-team/ionic-docs.git", "branch": "main" }]`
    log:
      error: Encountered error while running `git pull` on each of the `upstreamRemotes`
      start: Running `git pull` on each of the `upstreamRemotes`
      success: Successfully pulled from `upstreamRemotes`
    cmds:
      - task: common:update:upstream:remotes:pull

  reset:force:
    desc: 'Aggressively reset the project (**WARNING** This will wipe uncommitted work)'
    summary: |
      # Aggressively Reset Project

      This task will completely wipe the project by:

      1. Resetting to the HEAD
      2. Removing all files that are not included in source control (i.e. `node_modules/` etc.)
      3. Pulling the latest changes from `master`

      This task is essentially the equivalent of deleteing the project and re-cloning it.
    prompt:
      type: confirm
      message: Are you sure you want to forcefully reset the project?
      answer:
        cmds:
          - task: common:reset:force

  scripts:
    interactive: true
    deps:
      - install:npm:ntl
    desc: Run and view descriptions for `npm scripts` via an interactive dialog
    summary: |
      # Interactively Select Scripts Defined in package.json

      Our projects use `run` (a fork of task) to handle most of the task running.
      However, in some projects there may be scripts defined in package.json. This
      task is a convenience method that will present a list of scripts alongside
      their descriptions that you can interactively launch.
    log:
      start: Running `NTL_RUNNER=\{{.NPM_PROGRAM}} ntl`
      error: Error running `NTL_RUNNER=\{{.NPM_PROGRAM}} ntl`
    cmds:
      - NTL_RUNNER=\{{.NPM_PROGRAM}} ntl

  services:
    desc: Update elements of the repository that require API access
    summary: |
      # Update Elements of the Repository that Require API Access

      This task will ensure that the git repositories and other services related to the
      project are updated with the proper configurations. It requires that certain
      API keys be set. Generally, only project owners will use this task.
    cmds:
      - task: common:update:services
    status:
      - '[ -n "$GITLAB_CI" ] && [ "$REPOSITORY_UPDATE" != "true" ]'

  shell:
    desc: Start a terminal session using Docker with any Linux operating system
    compile: |
      '.tasks.common.shell = $this' common/Taskfile.yml
    summary: |
      # Start a Docker Terminal Session

      Use Docker to run commands on nearly any operating system. The operating
      systems are all stock distros with systemd added.

      The selected environment will mount the current working directory to the
      Docker container.

      **Example opening an interactive prompt:**
      `task shell`

      **Example of directly shelling into a container:**
      `task shell -- ubuntu-21.04`

      ## Available operating systems (that you can use with the example above):

      * archlinux
      * centos-7
      * centos-8
      * debian-9
      * debian-10
      * fedora-33
      * fedora-34
      * ubuntu-18.04
      * ubuntu-20.04
      * ubuntu-21.04
    cmds:
      - task: common:shell

  start:
    desc: Start the project by installing / updating dependencies, repairing issues, and opening a tutorial
    summary: |
      # Start the Project

      This task does everything that running `bash start.sh` does plus a little bit more:

      1. Installs Homebrew if it is not already installed
      2. Ensures Bodega is installed and up-to-date
      3. Ensures common system dependencies and runtimes
      4. Installs commonly used CLI tools
      5. Ensures local dependencies such as `node_modules` are installed
      6. Attempts to repair the project if it detects any issues

      It basically sets up all the tools you need, in advance so that problems can be detected as early
      as possible. In some cases, this command will open documentation or a tutorial to read while dependencies are being
      installed.
    log:
      start: Starting the project..
      success: Project started!
      error: Yikes! Error starting the project!
    cmds:
      - task: common:start

  synchronize:
    desc: Set up the project and refresh it with the latest changes
    summary: |
      # Start the Project

      This task will scaffold the project with the latest upstream changes
      and ensure your development environment has all the dependencies installed.

      This command should be used whenever the files that are automatically generated
      need to be updated. It also serves as an entry point for new developers who
      are getting started with the project.

      **Example usage:**
      `task start`
    log:
      start: Synchronizing project with upstream file changes and bootstrapping
      success: Successfully synchronized the project with upstream file changes and also bootstrapped the project
      error: Error encountered while starting up the project
    cmds:
      - task: upstream:\{{.PROJECT_TYPE}}

  tag:deps:
    desc: Inject a new command in the `Taskfile.yml` that includes all tasks matching a given tag as deps
    summary: |
      # Create Task with Deps Based on Tag

      Use this task to inject a new task in the `Taskfile.yml` that includes all the tasks
      that are tagged with a certain tag as deps. The tag must be supplied as a CLI argument.

      Say you have a task that looks like this:

      ```
      my-task:
        tags:
          - docker
        cmds:
          - docker volume ls
      ```

      Then, by running `task tag:deps -- docker`, you will get the following task injected into the
      `Taskfile.yml` file:

      ```
      deps:docker:
        deps:
          - my-task
      ```
    cmds:
      - task: common:util:task:tag:deps

  template:
    deps:
      - install:npm:liquidjs
    summary: |
      # Render a Template

      This task is provided to serve as an alias for developing new templated files.
    cmds:
      - |
        function handlebars() {
          FILE="$1"
          TMP="$(mktemp)"
          .config/log info 'Generating `'"${FILE//.liquid}"'` from `'"$FILE"'`'
          hbs --data .variables.json --helper ./.config/hbs.cjs "$FILE" --stdout > "$TMP"
          mv "$TMP" "${FILE//.liquid}"
          rm "$FILE"
        }
        handlebars '\{{.CLI_ARGS}}'
    preconditions:
      - sh: test -f .variables.json
        msg: This task requires that you have already spun up the project by running `task start`

  test:
    deps:
      - install:software:jq
      - install:software:node
    interactive: true
    desc: Open an interactive dialog to select and run a Molecule test
    vars:
      NONINTERACTIVE_MISSING_TEST_CMD: There must be a `.scripts.test` definition in `package.json`!
    summary: |
      # Test the Project

      This task calls `npm run test` which functions differently based on the
      definition made in `package.json` under the `.scripts.test` key.
      {{#eq group "ansible"}}
      ## Ansible Project Functionality

      For Ansible projects, this task wraps all the supported test methods for Ansible plays into a
      convenient multi-question prompt system that supports:

      1. Docker tests
      2. Headless VirtualBox tests
      3. VirtualBox Desktop tests which are not automatically destroyed
      4. Running the play locally
      5. Running the play over SSH on a remote target
      {{/eq}}
    cmds:
      - |
        if [ "$(jq '.scripts.test' package.json)" != 'null' ]; then
          npm run test
        else
          [[ $- == *i* ]] && task prepare || (.config/log error '\{{.NONINTERACTIVE_MISSING_TEST_CMD}}' && exit 1)
        fi

  update:
    desc: Fully update the repository
    summary: |
      # Update the Repository / Project

      This task will:

      1. Ensure Homebrew is installed
      2. Ensure runtimes like Node.js, Go, Python, and Poetry are installed
      3. Ensure the `PATH` environment variable is properly configured
      4. Configure the environment if it is in a `$CI` environment
      5. Run a repair script that is used to ensure older repositories are compatible with the Taskfile scripts
      6. Prepare the repository by automatically setting up certain parts of the project
      7. Run a full update on the repository with `task start`
      8. Automatically commit changes
      9. Update GitLab/GitHub repository settings if the `GITHUB_TOKEN` / `GITLAB_TOKEN` variables are set

      Along the way, if any dependencies are missing they will be installed as well just like with all of the
      tasks included in these Taskfiles.
    log:
      error: Failed to update the repository
      start: Updating the repository..
      success: Finished updating the repository
    cmds:
      - task: common:start
        env:
          UPDATE_PROJECT: 'true'
      - task: common:update:finish

  yubikey:
    desc: Create an OpenGPG-enabled YubiKey
    summary: |
      # Create an OpenGPG-enabled YubiKey SmartCard

      This task will walk you through creating an OpenGPG-enabled
      YubiKey. You can then use it to manage your GPG keys and SSH keys.
      It will prompt you for things like your pin and automatically
      set up the YubiKey.

      The interactive process simplifies this very popular guide on
      how to set up a YubiKey like this:

      [Guide on Using YubiKey for OpenGPG and SSH keys](https://github.com/drduh/YubiKey-Guide)

      We do still recommend that you skim through the guide.
    cmds:
      - |
        export GNUPGHOME="$HOME/.gnupgyubi"
        export MASTER_KEY="$(LC_ALL=C tr -dc '[:upper:]' < /dev/urandom | fold -w 30 | head -n1)"
        task security:yubikey:prepare