Ability to add custom metadata to pull requests

[Wazbat]

Is there any way to add custom information to pull requests? I'm setting up a ✨ fancy ✨CI system using github actions in my gitops repository, however I was wondering if there was any way we could add custom metadata to a PR?

For example, some PRs may or may not be trying to modify a kubernetes template, specifying an image digest to use. If the PR is indeed modifying an image digest/tag, I want to run certain tests, using stuff like the image digest, etc.

Now that's easy enough when creating the pull requests, as I have access to information about the code changes, in my case, when I create them from another action.

However, based on my understanding, there is no way to save any of that information for later. I can only control the following things:

• PR title
• PR body
• Labels
• Reviewers, projects, milestones, and other metadata

I've seen some hacky solutions, like using html comments to hide invisible metadata in PR bodies, however that feels like a really really janky solution, and not ideal

Is there any way around this? I feel this would be a great new feature, and would enable developers to make some pretty nifty intergrations without requiring a separate database to store this information

[Wazbat]

Now that I think about it, maybe I could output my metadata to a json file, then use https://github.com/actions/cache to store it in the repository cache to then fetch it later when running pull request checks? It's a shame there's no built in way, but I suppose that'd work?' Are there any better ways?

[airtower-luna]

The cache is not a reliable way to transmit data, cached data may get dropped whenever (usually when new objects need the space). Artifacts are reliable but have a limited lifetime, so they'll do for temporary data you want to pass to tools that run soon after PR creation, but not for data persistently associated with the PR.

[Wazbat]

The cache is not a reliable way to transmit data, cached data may get dropped whenever (usually when new objects need the space).

To be fair, I would only need the data immediately after the PR is created, when github runs the first pull request checks to make sure the PR is mergeable. I see the cache is supposed to last 7 days, or 10gb

Though artifacts do sound like they'd work, but aren't those stored on the job run? How would I find that in the PR?

[airtower-luna]

Artifacts are associated with a workflow run, yes. You'd probably have to look for the right workflow run (and then its artifacts) using the API. Not something I've done myself, but I know people have done that kind of thing.

And, well, how would you find a cache object from the PR? 😅

[Wazbat]

And, well, how would you find a cache object from the PR? 😅

Good question! Haha

I suppose I could use the pull request branch name or pull request number to build a unique cache key immediately after the PR is created. Then in the PR action, I can use the pull request context to fetch that object from cache

[gka038]

May I know if you found any great option to store metadata related to a PR?

[dmitrym0]

I recall seeing an action a while back that added hidden <!-- --> html to the description of the PR so that it wasn't visible to humans but was to the action. It was a simply hash-like API. Does anyone know what I'm referring to?

[alexkappa]

I think you are referring to probot/metadata.

[ericabouaf]

Found this thread looking for a similar solution on issues.
We ended up using Frontmatter with a triple backtick separator.

[kennethleider]

I am about to do this using git notes, was just searching for an example, but alas found none.

HASH=$(printf <pr_number> | git hash-object --stdin)
git notes --ref pull_request add -m "This is my metadata" $HASH
git notes --ref pull_request show $HASH
git push origin 'refs/notes/*'

and then when I need to read it

git fetch origin "+refs/notes/pull_request:refs/notes/pull_request"
HASH=$(printf <pr_number> | git hash-object --stdin)
git notes --ref pull_request show $HASH

[aviallon]

TIL git notes exists.

[michielbdejong]

@r-aaron-graham

you can use the GitHub API to store and retrieve metadata associated with pull requests

How? I wasn't able to find anything about this in the GitHub API docs.

[Wazbat]

I'm pretty sure he just pasted the thread into chatGPT and asked it to answer the question, and in typical fashion it just hallucinated everything, which combined with a lack of proofreading and blind-copy paste, just ended up confusing everyone more

[y-nk]

i'm tempted to consider this: https://cli.github.com/manual/gh_variable_set which is equivalent to leveraging secrets/variable as storage. it's not ideal either since there's a hard limit of 1k variables and that you need a PAT with specific permissions (Variables: write)

[y-nk]

if somebody reads this, i've made a github action for this: https://github.com/taskworld/pr-metadata-action

TLDR:

on:
  pull_request:

permissions:
  pull-requests: write

jobs:
  write-metadata:
    runs-on: ubuntu-latest
    steps:
      - uses: taskworld/pr-meta-action/write@v1
        with:
          data: '{"reviewed":true,"version":"1.2.3"}'
          merge: "true"

on:
  pull_request:

jobs:
  read-metadata:
    runs-on: ubuntu-latest
    steps:
      - id: meta
        uses: taskworld/pr-meta-action/read@v1
      - run: echo '${{ steps.meta.outputs.result }}' # {"reviewed":true,"version":"1.2.3"}
        if: steps.meta.outputs.has-metadata == 'true'

[doncjohn]

As far as I know, there still is not a native “custom metadata fields on a pull request” feature in GitHub itself.

The practical choices are mostly about how persistent and queryable you need the data to be:

1. Short-lived data between workflow jobs/runs

Use artifacts, not cache. Cache is an optimization layer and can disappear. Artifacts are tied to workflow runs and are more predictable, but they are still not really PR metadata.

2. Persistent data owned by automation

Use a hidden marker in the PR body or in a bot-authored comment. It is not elegant, but it is common because PRs are issues internally and comments/bodies are easy to read/update through the API.

Example marker:

<!-- pr-metadata:{"imageDigest":"sha256:...","templateChanged":true} -->

If you do this, make the automation own a clearly named block so it can update only that block and leave the human-written description alone.

3. Data you want visible/searchable in GitHub UI

Use labels, commit statuses, check runs, or PR comments. For example, a check run can expose structured output in its summary, and labels can represent coarse metadata like image-digest-changed.

4. Data you need to query reliably outside one PR

Use an external store keyed by repository_id + pull_request_number or pull_request_node_id. This is the least “GitHub-native” option, but it is the cleanest if the metadata matters operationally.

I would avoid using Actions cache or repository variables as the main metadata store. Cache is not durable enough, and repository variables are global, limited, and awkward for per-PR state.

For your use case, I would probably use one of these two patterns:

• If the metadata is only needed by CI immediately after PR creation: upload a JSON artifact and have later jobs/runs fetch it from the workflow run that created the PR.
• If the metadata should live with the PR: update a hidden JSON block in the PR body or in a single bot comment.

A native PR metadata API would definitely be cleaner, but until that exists, the bot-owned hidden block is usually the simplest durable GitHub-native workaround.