Skip to content

docs: use pull request safe git_ref and git_commit #726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
zentron wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: use pull request safe git_ref and git_commit #726

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,10 +56,12 @@ steps:
uses: OctopusDeploy/create-release-action@v4
with:
project: 'MyProject'
git_ref: ${{ github.ref }}
git_commit: ${{ github.sha }}
git_ref: ${{ github.head_ref || github.ref }}
git_commit: ${{ github.event.pull_request.head.sha || github.sha }}
```

Resolve both values per event so the release tracks the branch you built. On a pull request, `github.ref` is `refs/pull/<n>/merge` and `github.sha` is the merge commit that GitHub creates for the pull request. That commit is not reachable from any branch or tag, so a release pinned to it can fail to deploy later. `github.head_ref` and `github.event.pull_request.head.sha` give you the source branch and its head commit, and both fall back to the push values on every other event.

To specify the version of a package referenced in a step to use in the release, add the `packages` field:

```yml
Expand Down Expand Up @@ -115,8 +117,8 @@ steps:
| `package_version` | The version number of all packages to use for this release. |
| `packages` | A multi-line list of version numbers to use for a package in the release. Format: StepName:Version or PackageID:Version or StepName:PackageName:Version. StepName, PackageID, and PackageName can be replaced with an asterisk ("\*"). An asterisk will be assumed for StepName, PackageID, or PackageName if they are omitted. **NOTE** these values should not be enclosed in single-quotes (`'`) |
| `git_resources` | A multi-line list of Git references to use for a step's Git resource, resolved at release-creation time. Useful for steps that read from a Git repository — such as **Update Argo CD Application Manifests** — so a release can target a specific branch/tag (e.g. a feature branch). Format: StepName:GitRef or StepName:GitResourceName:GitRef (e.g. `Update Argo CD Application Manifests:refs/heads/my-feature`). Note: `git_ref`/`git_commit` select the version-controlled project's own OCL branch; `git_resources` selects the branch/tag of a Git resource used by a step. |
| `git_ref` | Git reference, _branch name or tag_, to the specific resources of a version controlled Octopus Project. This should be used for version controlled projects when OCL files are stored in a different repository or branch as the application being built. E.g. Use the `main` branch, regardless of the location of the repository where the application(s) are being built as they are different **or** `${{ github.ref }}` to use the branch or tag ref that triggered the workflow. |
| `git_commit` | Git commit, _commit SHA-1 hash_, pointing to the specific resources of a version controlled Octopus Project. This should be used for version controlled projects when OCL files are stored in the same repository or branch as the application being built. E.g. `${{ github.sha }}` to use the commit that triggered the workflow. |
| `git_ref` | Git reference, _branch name or tag_, to the specific resources of a version controlled Octopus Project. This should be used for version controlled projects when OCL files are stored in a different repository or branch as the application being built. E.g. Use the `main` branch, regardless of the location of the repository where the application(s) are being built as they are different **or** `${{ github.head_ref \|\| github.ref }}` to use the branch or tag that triggered the workflow. Avoid `${{ github.ref }}` on its own, because on a pull request it is `refs/pull/<n>/merge` and pins the release to a merge commit that no branch reaches. |
| `git_commit` | Git commit, _commit SHA-1 hash_, pointing to the specific resources of a version controlled Octopus Project. This should be used for version controlled projects when OCL files are stored in the same repository or branch as the application being built. E.g. `${{ github.event.pull_request.head.sha \|\| github.sha }}` to use the commit that triggered the workflow. Avoid `${{ github.sha }}` on its own, because on a pull request it is the merge commit GitHub creates for the pull request rather than the head of the branch that was built. |
| `ignore_existing` | Ignore existing releases if present in Octopus Deploy with the matching version number. Defaults to **false** |
| `release_notes` | The release notes text associated with the new release (Markdown is supported). |
| `release_notes_file` | A file containing the release notes associated with the new release (Markdown is supported). Use either `release_notes` or this input, supplying both is not supported. |
Expand Down