The wtfjoke/setup-tectonic action is a JavaScript action that sets up Tectonic in your GitHub Actions workflow by:

• Downloading a requested version of Tectonic and adding it to the PATH.
• (Optionally) downloading a requested version of Biber and adding it to the PATH.

This action can be run on ubuntu-latest, windows-latest, and macos-latest GitHub Actions runners.

The default configuration installs the latest version of Tectonic. The GITHUB_TOKEN is needed to query the Github Releases of tectonic-typesetting/tectonic to download tectonic.

You can even use caching (see example below) to speed up your workflow 🎉.

See action.yml for a full description of all parameters.

steps:
  - uses: wtfjoke/setup-tectonic@v3
    with:
      github-token: ${{ secrets.GITHUB_TOKEN }}
  - run: tectonic main.tex

You can also download a specific version of Tectonic

steps:
  - uses: wtfjoke/setup-tectonic@v3
    with:
      github-token: ${{ secrets.GITHUB_TOKEN }}
      tectonic-version: 0.12.0
  - run: tectonic main.tex

If you want to use biber, specify a biber version (for a full example see below)

steps:
  - uses: wtfjoke/setup-tectonic@v3
    with:
      github-token: ${{ secrets.GITHUB_TOKEN }}
      biber-version: 2.16
  - run: biber --version

name: 'Build LaTex Document'
on:
  push:
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - uses: wtfjoke/setup-tectonic@v3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
      - name: Run Tectonic
        run: tectonic main.tex
      - name: Upload pdf
        uses: actions/upload-artifact@v3
        with:
          name: main
          path: main.pdf

name: 'Build LaTex Document'
on:
  push:
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - uses: actions/cache@v3
        name: Tectonic Cache
        with:
          path: ~/.cache/Tectonic
          key: ${{ runner.os }}-tectonic-${{ hashFiles('**/*.tex') }}
          restore-keys: |
            ${{ runner.os }}-tectonic-
      - uses: wtfjoke/setup-tectonic@v3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
      - name: Run Tectonic
        run: tectonic main.tex
      - name: Upload pdf
        uses: actions/upload-artifact@v3
        with:
          name: main
          path: main.pdf

name: 'Build LaTex Document with Biber'
on:
  push:
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - uses: actions/cache@v3
        name: Tectonic Cache
        with:
          path: ~/.cache/Tectonic
          key: ${{ runner.os }}-tectonic-${{ hashFiles('**/*.tex') }}
          restore-keys: |
            ${{ runner.os }}-tectonic-
      - uses: wtfjoke/setup-tectonic@v3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          biber-version: 'latest'
      - name: Run Tectonic + Biber
        run: tectonic main.tex
      - name: Upload pdf
        uses: actions/upload-artifact@v3
        with:
          name: main
          path: main.pdf

Note: Tectonic has added biber support in 0.7.1 (see changelog). Prior to that version you need to run following commands:

run: |
  tectonic --keep-intermediates --reruns 0 main.tex
  biber main
  tectonic main.tex

This action was created because all existing Github Actions for compiling LaTeX documents I came across are docker based actions, which are slower than Javascript based actions.

LaTex Docker images tend to be huge (2gb+). Tectonic images are an exception but they need to be maintained and updated with new Tectonic versions. This is not often the case, at the time of writing my docker image is the only one up to date with the latest tectonic version.

In comparison, this github action doesn't need an update if a new release of tectonic is released, it just works.

The existing github actions doesn't support biber (notable exception: birjolaxew/tectonic-biber-action).

Additionally most of the github actions tend to do too much or are too strict.

This github action has one job, to setup tectonic (and optionally biber). You can choose on your own how you want to call tectonic, how and if you want to cache your dependencies, how and if you want to upload your pdf. Depending on your decisions you can choose the best action to do the corresponding job (eg. actions/cache for caching, actions/upload-artifact or actions/create-release for publishing your pdf)

The official cache action actions/cache has three parameters:

• path - A list of files, directories, and wildcard patterns to cache and restore.
• key - Primary cache key - If the key has a cache-hit, it means the cache is up to date. The execution of a tool should'nt change the cache anymore.
• restore-keys - If there is no key hit with key - These will be used to restore the cache. The execution of a tool most likely will change the cache.

For tectonic the cache directories (path) are as follows (see also tectonic-typesetting/tectonic#159):

| OS | Cache-Directory | Run-Command to export it as environment variable | | ------- | ----------------------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------------- | | Linux | ~/.cache/Tectonic | echo TECTONIC_CACHE_PATH=~/.cache/Tectonic >> $GITHUB_ENV | | Mac | ~/Library/Caches/Tectonic | echo TECTONIC_CACHE_PATH=~/Library/Caches/Tectonic >> $GITHUB_ENV | | Windows | %LOCALAPPDATA%\TectonicProject\Tectonic | echo TECTONIC_CACHE_PATH=$env:LOCALAPPDATA\TectonicProject\Tectonic | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append` |

By calculate the hash all .tex files (see hashFiles('**/*.tex')) and integrate that into the cache-key we can make sure, that another execution of tectonic wont change the result.

Simpler put, as long as no .tex files are changing, the cache wont change.

We change our .tex files but still want to use a cache? restore-keys to the rescue 💪

When we change our .tex files (either by using a new package or just change the text), the exact cache key wont hit. Still we want to use the cache from the previous runs, as we most likely still use the same packages. So restore keys will use the cache from the previous run and then (at the end of the job execution) will update the existing cache with key.