name
An alphanumeric string (underscores are permitted) that identifies the resource.
type
Must be GitRepo
for this resource type.
configuration
Specifies all configuration selections for the resource.
Tag | Description | Required/Optional |
---|---|---|
| The name of the source control integration. Currently supported integration types are: | Required |
| The path of the repository from the integration root. The path can be hard coded or you can use Example - name: myFirstRepo type: GitRepo configuration: gitProvider: myGitHub path: {{.jfrog-pipelines.sourceRepository}} | Required |
|
Note
| Optional |
|
Supported regexThe
Examples:
NoteIf the tag is not specified, the default branch will be triggered. | Optional |
| Set as | Optional |
|
NoteIf this tag is not specified, all branches are matched by default. | Optional |
|
NoteIf this tag is not specified, the | Optional |
| Used to specify a collection of tags and releases upon which a new version is created
NoteIf this tag is not specified, all tags are matched by default. | Optional |
| Used to control whether the resource will be updated on specified events
NoteIf this tag is not specified, For more information about using this tag, see Triggering On a Git Repository Change. | Optional |
| Used to control whether previously triggered runs are canceled for new webhooks
NoteAll values for this tag are false by default. For more information about using this tag, see Cancelling Previous Runs On a Git Repository Change. | Optional |
| Uses a positive integer to set the depth at which the repo is (shallow) cloned/fetched NoteIf | Optional |
| Used to select the protocol to be used when cloning the repo. Supported values are | Optional |
| This configuration can be used to pin the resource to a specific version. The pinned resource version will be used by the steps that reference this resource as an input and newer versions will be ignored. Users have two configuration options when selecting the GitRepo resource version to be pinned:
Or
Steps that use the resource as an output can still produce new versions. New versions will be visible for steps using the resource as an input as long as they are part of the same run of the step that created the version. When creating a new run, manual custom trigger can still be used to override the pinned version to a different one. | Optional |
Using Include and Exclude Patterns
When both include and exclude patterns are used, the following rules apply on the list of all the files in the commit change list :
All files that do not match the include pattern are removed
All files that do match the exclude pattern are removed
If any files are left, the resource is updated