...
The password used to login to GitHub. This should have access to the repository you are managing releases for.
GitHub Access Token
The personal API access token used to login to GitHub. This should have access to the repository you are managing releases for. Supply either an access token or a username and password combination above.
Repository
Select a GitHub repository from the remote Git repositories associated with the configuration.
...
- Create new release: A new release will be created with the specified tag name and on the specified target commit. This will fail if the release already exists in the repository..
- Edit existing release: An existing release with the supplied tag name will be updated with the supplied details.This will raise an error if the tag does not exist, unless the "Ignore errors if existing release is not found when deleting or updating. Log warning only" option is ticked.
- Delete existing release: An existing release with the supplied tag name will be deleted. This will raise an error if the tag does not exist, unless the "Ignore errors if existing release is not found when deleting or updating. Log warning only" option is ticked.
Release Details
Tag Name
The name of the GitHub tag identifying the release to create, edit or delete. This should be a version number which follows the semantic versioning format rules.
Target Commit
The Git commit to mark as a release. This checkbox is displayed when the "Create new release" operation is selected. The following options are available
- Branch associated with build: The release will be created for the head commit of the branch of the repository associated with the current build.
- First changeset associated with the build: The release will be created for the first changeset commit associated with the current build.
- Last changeset associated with the build: The release will be created for the lasr changeset commit associated with the current build.
- Default branch: The release will be created for the head commit of the default branch of the repository as defined in GitHub.
- Specific branch or commit: This option causes the Specific Commit Hash or Branch Name field to be displayed.
Specific Commit Hash or Branch Name
The specific commit hash of branch head name to mark as a release.
Release Name
The name or title of the GitHub release. If left empty the tag name is used.
Description
The description of the GitHub release. You can use GitHub markdown tags here.
Draft
Tick this checkbox to save the release as a draft.
Pre-release
Tick this checkbox to flag the release as non-production ready.
Assets
Artifacts to Upload
A list of paths to files to upload from the server workspace. Note that you will need to set up your workspace rules to ensure that the relevant build output files are copied from the agent to the server workspace.
Each file/pattern must be entered on a new line. You can specify an exact file with its path or you can use pattern matching.
You can exclude files by prefixing the file name or pattern with a dash. e.g -*.ignore. Exclude patterns always take precedence over include patterns. More information about pattern wild cards can be found on the Ant Pattern Usage page.
Delete and replace any existing release assets with the same name
Tick this checkbox to delete any existing release assets with the same name before uploading the new updated assets.
When To Run
You can specfy when the build event handler runs by linking it to a Build Event on the When To Run tab
Build Event
Select the event which triggers the tag action. You can choose one of the following Build Events:
- On Build Created
- On Before Build Queued
- On Before Build Start
- On After Build Started
- On Before Stage Start
- On Sending Stage To Agent
- On Stage Completed
- On Build Pending Promotion
- On Before Build Continue
- On After Build Continued
- On Build Stopping
- On Build Completed
Stage
For stage events, select the stage this applies to, or "(all stages)" to trigger the tagging action for all stages
Build Status
For "On Stage Completed" and "On Build Completed", you can choose to trigger the tagging action when the build is Successful or has Failed.
Options
Wait for result
Clear this option to run the tagging action in a separate thread if you don't care about the result eg. whether the action fails or not.
Fail build on error
Tick this to fail the build if the operation returns an error or failure. This is only available if Wait for result is ticked.
Ignore errors uploading artifacts. Log warning only
An error result will be returned if an artifact fails to upload. Tick this option to ignore these errors, only logging a warning to the build log.
Ignore errors if existing release is not found when deleting or updating. Log warning only
An error result will be returned if a release with a matching tag name is not found. Tick this option to ignore these errors, only logging a warning to the build log.
Fail build on error
Tick this to fail the build if the operation returns an error or failure. This is only available if Wait for result is ticked.
Log build messages
When this is ticked, Continua CI will add messages to the build log during execution of the GitHub Release action. Build log messages will only be recorded if Wait for Result is ticked.