> For the complete documentation index, see [llms.txt](https://docs.currents.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.currents.dev/getting-started/ci-setup/github-actions/commit-data-for-github-actions.md).

# Commit data for GitHub Actions

How to get correct git commit information when using GitHub Actions

### GitHub Pull Request Title, Issue Link and Branch Name

{% hint style="info" %}
**Update Jan 30, 2024**

`@currents/playwright@0.12.0` and `cypress-cloud@1.10.0` automatically detect Pull Request information when running in GitHub Actions.
{% endhint %}

The recent (Jan 30, 2024) releases of `@currents/playwright@0.12.0` and `cypress-cloud@1.10.0` handles git information better when running in GitHub Actions triggered by `` `pull_request` `` trigger.

* PR title becomes Run Title (instead of a generic message PR #XX)
* Effective Branch becomes the PR HEAD branch name - allowing more meaningful usage in analytics and notification filters
* UI displays a direct link to GitHub Pull Request issue

<figure><img src="https://3745692499-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqmFDEiUa9mr11LUlxDnt%2Fuploads%2FXccp1KAtQsvKZ1GUA5AW%2Fcurrents-2024-01-30-14.57.07%402x.png?alt=media&amp;token=a2ef75e7-ac46-4cab-9f70-16f3bf82fb70" alt=""><figcaption><p>Capturing GitHub PR data</p></figcaption></figure>

### Merge commit in pull request runs

{% hint style="info" %}
`@currents/playwright@2.5.1` and `@currents/cmd@1.11.0` record the last commit of the pull request when GitHub Actions checks out a merge commit.
{% endhint %}

On [`pull_request`](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request) events, `actions/checkout` checks out a merge commit that GitHub creates by merging the pull request into the base branch. Its message looks like this:

```
Merge de7282540ac30ee4e32a0b1fede4f6391b4cc321 into fa58941d8a807b83ec5a3e5bfb83418ce12173c7
```

The reporter detects the merge commit and records the last commit of the pull request instead: its SHA, message, author and timestamp.

With the default `actions/checkout` settings, the clone has only the merge commit, so the reporter fetches the pull request commit:

```
git fetch --depth=1 --no-tags origin <pull request commit SHA>
```

The fetch uses the credentials that `actions/checkout` stores in the clone, and times out after 3 seconds. If it fails, the run shows the merge commit's message and author, as with earlier versions. For example, the fetch fails in a private repository checked out with `persist-credentials: false`. The commit SHA and branch still come from the pull request, so PR comments and commit statuses are not affected.

To turn the fetch off, set `CURRENTS_DISABLE_HEAD_COMMIT_FETCH=true`. See [Commit Information](/dashboard/runs/commit-information.md) for other CI providers.

#### Earlier versions and Cypress

With `cypress-cloud` and earlier versions of the reporters, runs show the merge commit's message and author. To record the last commit of the pull request, check out that commit:

```yaml
- uses: actions/checkout@v4
  with:
    ref: ${{ github.event.pull_request.head.sha }}
```

The workflow then tests the last commit of the pull request, not the result of merging it into the base branch. It does not catch conflicts or failures that appear only after the merge.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.currents.dev/getting-started/ci-setup/github-actions/commit-data-for-github-actions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
