Matrix jobs with titles longer than 100 characters can't find their `job_id`

[karolba]

First of all, thank you for this great project!

Describe the bug

Matrix jobs with titles longer than 100 characters can't find their job_id, because GitHub is truncating the job title.

This truncation sadly also happens through the API:

$  gh api /repos/karolba/tf-via-pr-repro/actions/runs/16523799334/attempts/1/jobs | jq '.jobs[].name'
"test (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa..."

To Reproduce

Something like this:

on:
  workflow_dispatch:
    inputs:
      matrix-parameter:
        description: '...'
        type: string
        required: true

jobs:
  test:
    runs-on: ubuntu-latest

    permissions:
      actions: read
      checks: write
      contents: read
      pull-requests: write

    strategy:
      matrix:
        include:
          - value: ${{ inputs.matrix-parameter }}

    steps:
      - uses: actions/checkout@v4

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_wrapper: false

      - uses: op5dev/tf-via-pr@v13
        with:
          working-directory: .
          command: init
          arg-backend: false

Succeeded run, a short title: https://github.com/karolba/tf-via-pr-repro/actions/runs/16523783785/job/46731746350
Failed run, a long truncated title: https://github.com/karolba/tf-via-pr-repro/actions/runs/16523799334/job/46731800838

Screenshots

Additional context

I could provide a PR fixing this but I'm not sure it's really possible with how the GitHub API currently works. I've found this approach: https://github.com/qoomon/actions--context/blob/486c37d6b227e8f01d8694a92e89d88b6c454281/lib/actions.ts#L235-L294 that makes use of .jobs[].runner_name having semi-unique names (they look like "GitHub Actions 1000000072" for GitHub-hosted runners).

This seems like a good idea, however I have no idea this value would also be unique for all setups with self-hosted runners.

I did check some jobs based on runs-on.com runners I have access to and this seems to hold though:

$ gh api /repos/[...]/[...]/actions/runs/[...]/attempts/1/jobs | jq '.jobs[].runner_name'
"GitHub Actions 1000023117"
"runs-on--i-0ace19af4d869a39e--AkrIiniYYc"
"GitHub Actions 1000023118"
"runs-on--i-061f5900650d83914--mYSLfAOwJN"
"runs-on--i-096e31255c6fec8d5--NZwDVaXmgC"
"runs-on--i-07aa7ff96b9ecd616--vlHoMysSsQ"
"runs-on--i-0bb3438f22f065b97--DtQDPCJSTg"
"runs-on--i-04f2a9668d2ffdd06--OztLfCgeCJ"
"runs-on--i-031f9c288d61ff213--ZjBHjPDrSC"
"runs-on--i-0d9d1a48bece2f80d--GCXbgXsQBT"
"runs-on--i-09771e51b1002c522--XhtuJQeLtM"
"runs-on--i-05fee9d31716c2970--ZYcCScojku"
"runs-on--i-0f8d9a0becf75deda--qSXeEGvhyf"
"runs-on--i-07b156e010a3ef8eb--SiskFvGdQv"
"GitHub Actions 1000023124"
"GitHub Actions 1000023125"

[rdhar]

First off, fantastic issue and really appreciate you taking the time to walk through the problem and clarify your steps + context. Creating a mini-repo just to help reproduce the issue easily is next-level - thank you!

Admittedly, I'm very curious by the first screenshot: are you using TF-via-PR in the same workflow as Terragrunt? Only asking because I've long wanted to add first-class Terragrunt support, but lacking the expertise to do it properly, so I'm keen to hear of your workflow use-case and how you're finding it.

Back on-topic, the job ID determination step is so annoyingly unnecessary: this li'l piece of data should be available by default instead of having to make additional API requests for it. As of last month, a GitHub representative confirmed they're working on adding job check run ID to the expression context, which should address this very issue.

In the same discussion, there's a person who found a workaround relying on "job UUID", as well as the actions--context solution that you linked.

At this point, I'm not certain what the next steps should be. Although I'm tempted to wait for GitHub to officially fix this at the API level, I also don't want this project to be unsuitable in the meantime for users with rather long job names. That seems silly.

[karolba]

Admittedly, I'm very curious by the first screenshot: are you using TF-via-PR in the same workflow as Terragrunt? Only asking because I've long wanted to add #258, but lacking the expertise to do it properly, so I'm keen to hear of your workflow use-case and how you're finding it.

I sort of hacked-it-together to make terragrunt invocations look like terraform invocations with a script that looks like this, and it seems to be working fine so far:

#!/bin/bash

# This makes the tf-via-pr action interact with terragrunt when it's thinking it's talking to tofu

# Don't make terragrunt prefix the logs (we only invoke one module anyway)
export TG_LOG_FORMAT=bare
export TG_TF_FORWARD_STDOUT=true

# Don't run `tofu outputs -get=false` for each dependant output (slow) but let terragrunt fetch state from s3 by itself
export TG_DEPENDENCY_FETCH_OUTPUT_FROM_STATE=true

# Don't assume the answer to "apply external dependency?" is "yes" - this is almost never what we want
export TG_QUEUE_EXCLUDE_EXTERNAL=true

if [[ $1 == -chdir=* ]]; then
	# terragrunt has no -chdir flag, so emulate it
	cd "${1#-chdir=}" || exit $?
	shift
fi

if [[ $1 == plan ]]; then
	# coerce terragrunt into storing the planfile in the current directory like tf/tofu
	# The terragrunt docs suggest --working-dir=, --out-dir=, or TG_OUT_DIR= should switch
	# where the plan file ends up. This does not happen.
	# So we have to modify the -out=tfplan argument to have an absolute path (-out=/.../tfplan)
	args=()
	for arg; do
		case "$arg" in
			-out=*) args+=( -out="$(realpath "${arg#-out=}")" ) ;;
			*) args+=( "$arg" ) ;;
		esac
	done
else
	args=( "$@" )
fi

set -x
exec terragrunt --no-color run -- "${args[@]}"

At this point, I'm not certain what the next steps should be. Although I'm tempted to wait for GitHub to officially fix this at the API level, I also don't want this project to be unsuitable in the meantime for users with rather long job names. That seems silly.

Considering it looks like there's many ways to do this that might not work equally well for everyone, what do you think about just making this an optional input for now until GitHub finally adds an official way to query the job id?

[rdhar]

I sort of hacked-it-together to make terragrunt invocations look like terraform invocations with a script that looks like this, and it seems to be working fine so far:

Thanks so much for sharing this snippet -- I can't believe you haven't already showed up in the pinned #258 issue about implementing Terragrunt support! Would love to have your participation in that thread, especially if you could share any examples of demo projects and associated Terragrunt commands to run. At a basic-level, I understand that Terragrunt runs apply with auto-approve by default, so I wonder if storage/retrieval of plan-file is even relevant in that scenario?

[karolba]

At a basic-level, I understand that Terragrunt runs apply with auto-approve by default

I don't think that's true (in my experience at least), maybe if you use the plan-all and apply-all commands that holds? I feel like terragrunt is just a "thing" that defines inputs to modules and dependencies between them, you can hold it in many ways.

I planned to contribute something to support Terragrunt here (I missed the #258 issue), but:

• there'd have to be a way to trigger plans/applies only on changed modules - or modules that have their dependant modules and included files changed. However this seems to be very buggy in terragrunt. You can kinda get this with terragrunt render --all --json --with-metadata --write but that seems to:
  • break terragrunt's find_in_parent_folders() function for some reason
  • work very slow if you're using anything else but AWS S3 for storing state (there seems to be no option to skip getting state - even though it shouldn't really be neccessary)
  • not really show location of dependant included variables (if you include a file that includes a file it will only show the path to the first one)
• and you'd have to behave the way plan-all and apply-all do in terragrunt - that is, do dependant modules first, then their dependencies, etc
  • this doesn't seem that hard to do but the only way to get that ordering information is to either reconstruct it from terragrunt render --all --json --with-metadata --write (which seems very buggy) or to use terragrunt dag graph which generates a.. .dot graphviz-style file with all the modules ordered.

Considering how broken this feels I just gave up. The terragrunt folks are planning to do their own managed CI solution and go to a v1.0.0 soon, so maybe things are going to improve in the future as they add stuff related to that

[rdhar]

Happy to see this shipped with v13.6.1 (v13), where your contribution has been credited!

Please consider ⭐ this project, if you or your team find it useful.

---

@karolba Thanks once again for raising such a detailed issue! While there're a few ways of going about this, I'm admittedly apprehensive of including an optional input for something as critical as the job ID. Not least of which because the eventual removal of the input would be a breaking change -- which is never fun to deal with.

As it turns out, all it took was hitting jq v1.7's manual to learn about the inverse function of contains: inside. Combined with some string manipulation, it's reasonably reliable at determining the job ID even with extra-long names (limitations discussed here).

Almost goes without saying, keen to hear how you get along and wide-open for any other thoughts or feedback you'd like to share!