Cloud customer?
开始免费>
Upgrade in MyJFrog >
What's New in Cloud >





概述

AGitRepois used to connect JFrog Pipelines to a source control repository. Adding it creates a webhook to the repo so that future commits will automatically create a new version with the webhook payload.


The first version of the resource, used if it is an input to a step that runs before any webhooks are received, will be for the latest commit in the default branch on the source provider at the time the resource is created. Later resource versions can be restricted by the branches , tags , and buildOn options.

To suppress triggering for an individual commit, include the textskipRunin the commit message.

By default theGitReporesource usessshprotocol with the created deploy key to fetch the source repository content. However, this only provides Pipelines with read-only access to the source repository. Optionally, users can configure aGitReporesource to usehttpsprotocol. In this case Pipelines will have privileges to the source repository according to the credentials used to set up the Git provider integration.

Page Contents

Related Content

YAML Schema

resources: - name:  type: GitRepo configuration: gitProvider:  path:  files: include:  exclude:  branches: include:  exclude:  pullRequestSourceBranches: include:  exclude:  pullRequestTargetBranches: include:  exclude:  tags: include:  exclude:  buildOn: commit:  pullRequestCreate:  pullRequestClose:  releaseCreate:  tagCreate:  cancelPendingRunsOn: newCommit:  pullRequestUpdate:  shallowDepth:  # used to set the depth at which the repo is (shallow)cloned/fetched cloneProtocol:  # Optional. Defaults to ssh pin: versionId:  sha: 

Tags

name

Analphanumericstring (underscores are permitted) that identifies the resource.

type

必须GitRepofor this resource type.

configuration

Specifies all configuration selections for the resource.


Tag

Description

Required/Optional

gitProvider

The name of the source control integration.Currently supported integration types are: Required
path
The path of the repository from the integration root
Required

files
  • include-- (optional) Regular expression to include files meeting the pattern from the repo
  • exclude-- (optional) Regular expression to exclude files meeting the pattern from the repo
  • If this tag is not specified, all files are matched by default.
  • This filter only applies to commit events, and not pull requests, tags, or releases.
Optional

branches

  • include-- (optional) Regular expression to include branches from the repo
  • exclude-- (optional) Regular expression to exclude branches from the repo

Supported regex

Thebranchestag supports the following regex:

^ $ . *&? @ = ; :+

Examples:

^gitBranch$(to trigger for that branch)

example.*

example+.&

example+:&@=.*$

^._example+:&.@=+;?.*$

example+.:&@=*;?1661337986460$

If the tag is not specified, the default branch will be triggered.

Optional
pullRequestSourceBranches
  • include-- (optional) Regular expression to include pull requests from branches matching the pattern
  • exclude-- (optional) Regular expression to exclude pull requests from branches matching the pattern

If this tag is not specified, all branches are matched by default.

Optional
pullRequestTargetBranches
  • include-- (optional) Regular expression to include pull requests to branches matching the pattern
  • exclude-- (optional) Regular expression to exclude pull requests to branches matching the pattern

If this tag is not specified, thebranchestag setting will apply to the target branch. If neither is specified, all branches are matched by default.

Optional
tags

Used to specify a collection of tags and releases upon which a new version is created

  • include-- (optional) Regular expression to include tags meeting the pattern from the repo
  • exclude-- (optional) Regular expression to exclude tags meeting the pattern from the repo

If this tag is not specified, all tags are matched by default.

Optional
buildOn

Used to control whether the resource will be updated on specified events

  • commit-- (default is true) used to control whether the resource will be updated for commit webhooks. Note that when this is set asfalse, the resource is not updated and the resource version is not created.
  • pullRequestCreate-- (default is false) used to control whether the resource will be updated for pull request webhooks
  • pullRequestClose-- (default is false) used to control whether the resource will be updated for closing a pull request webhook
  • releaseRequestCreate-- (default is false) used to control whether the resource will be updated for release webhooks
  • tagCreate-- (default is false) used to control whether the resource will be updated for tag webhooks

    In a multi-branch pipeline, whentagCreateis set astrueand when you perform a commit or Git release with a specific tag, buildOn.commit will trigger only those branches that have the associated Git tag.

    This is applicable for GitHub only.

If this tag is not specified,commit:trueis the default setting.

For more information about using this tag, seeTriggering On a Git Repository Change.

Optional
cancelPendingRunsOn

Used to control whether previously triggered runs are canceled for new webhooks

  • newCommit-- (default is false) Cancels previous processing or waiting runs for the same branch for commits, same tag name for tags, and same release name for releases.
  • pullRequestUpdate-- (default is false) Cancels previous processing or waiting runs for the same pull request number when a webhook is received for a pull request.

All values for this tag are false by default.

For more information about using this tag, seeCancelling Previous Runs On a Git Repository Change.

Optional
shallowDepth

Uses a positive integer to set the depth at which the repo is (shallow) cloned/fetched

IfshallowDepthis not specified, no shallow clone options are passed to git. The full repo is cloned in its entirety.

Optional
cloneProtocol Used to select the protocol to be used when cloning the repo. Supported values aresshorhttps. Defaults tossh. Optional
pin

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:

  • versionId-- Resource version Id (can be obtained through the UI)

  • sha--The commit sha to be pinned

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 triggercan still be used to override the pinned version to a different one.

Optional




Environment Variables

WheneverGitRepois used in a step, a set of environment variables is automatically made available that you can use in your step.

Environment Variable Description
res__path
Relative path of the resource
res__branchName
Name of branch on which the commit occurred. If it was created for a pull request, this is the base branch
res__commitMessage
Commit message of the version being used
res__commitSha
SHA of the commit of the version being used
res__commitUrl
URL to the commit
res__committerLogin
Name of the committer for the SHA being used
res__gitProvider_name
Git integration name
res__gitProvider_url
URL of the Git Provider integration
res__gitRepoFullName
Name of the Git repo
res__gitRepoRepositoryHttpsUrl
HTTPS URL for the Git repository
res__gitRepoRepositorySshUrl
SSH URL for the Git repository.
res__gitRepoRepositoryUrl
URL for the Git repository
res__gitRepoSourceDefaultBranch
Default branch of the Git repository
res__gitTagName
If a tag name was present in the current version, this will be the tag name
res__integrationName
Thenamestring of the integration used by the GitRepo
res__isGitTag
Trueif the version is a git tag based build
res__isPrerelease
Trueif the version is a git release based build. Supported only if the integration is GitHub
res__isPullRequest
Trueif the version is a git open pull request based build
res__isPullRequestClose
True,if the version is a git closed pull request based step. Supported only if the integration is GitHub or Bitbucket or Gitlab.
res__isRelease
Trueif the version is a git release based build. Supported only if the integration is GitHub
res__pullRequestNumber
The ID number of the pull request
res__pullRequestBaseBranch
Name of the base branch into which the pull request changes will be merged
res__pullRequestSourceUrl
Source URL of the pull request
res__pullRequestSourceHttpsUrl
Source HTTPS URL of the pull request
res__pullRequestSourceSshUrl
Source SSH URL of the pull request
res__resourcePath
Full path of the resource folder on the node
res__operation
Input or output resource
res__shaData

JSON对象包含沙的细节

res__beforeCommitSha
沙性能试验ore the commit was made
res__baseCommitRef
The commit SHA of base branch in a PR
res__compareUrl
Compare URL for the commit
res__gitTagMessage
If a git tag is created, this holds the message if it is present
res__releaseName
If a release is created, this holds the name of the release
res__releaseBody
If a release is created, this holds the description of the release
res__releasedAt
If a release is created, this holds the date of the release
res__lastAuthorLogin
Details of when the last author logged in
res__lastAuthorEmail
Email of the author
res__isBranchCreate
Trueif a branch was created
res__isBranchDelete
Trueif a branch was deleted

Examples

Example 1

GitRepo resource listening to the master branch
resources: - name: my_app_repo type: GitRepo configuration: gitProvider: my_github path: myuser/repo-name branches: include: master

Example 2

GitRepo resource listening to all branches except master and release
resources: - name: my_app_repo type: GitRepo configuration: gitProvider: my_github path: myuser/repo-name branches: exclude: ^(master|release)$

Example 3

The following example may be useful to reference a single directory in a source repository that contains source code for a single microservice within a larger project.

GitRepo resource listening only to certain files in a directory
resources: - name: my_app_repo type: GitRepo configuration: gitProvider: my_github path: myuser/repo-name branches: include: master files: include: ^folder1\/package\/docker\/micro1\/.+

Example 4

By default, a GitRepo triggers on a commit, but this can be changed in thebuildOnattributes. For more information about triggering, seeTriggering Pipelines and Steps.

GitRepo triggers only for a pull request and not for commit
resources: - name: my_app_repo type: GitRepo configuration: gitProvider: my_github path: myuser/repo-name branches: include: master buildOn: commit: false pullRequestCreate: true

Example 5

The following example pipeline triggers the first step on the GitRepo resource. The step uses the environment variables exposed by the GitRepo resource to navigate to the path where the git repository is cloned on the build node, and to execute a script in that directory.

Usage in a Pipeline
pipelines: - name: java_pipeline steps: - name: step_1 type: Bash configuration: inputResources: - name: my_app_repo execution: onExecute: - pushd $res_my_app_repo_resourcePath - ./execute.sh - popd

Example 6

GitRepo resource using HTTPS protocol during repo clone
resources: - name: my_app_repo type: GitRepo configuration: gitProvider: my_github path: myuser/repo-name branches: include: master cloneProtocol: https

Example 7

在这个例子中,GitRepo辊筒y updated for pull requests to master.

GitRepo triggers only for a pull requests to master
resources: - name: my_app_repo type: GitRepo configuration: gitProvider: my_github path: myuser/repo-name pullRequestTargetBranches: include: ^master$ buildOn: commit: false pullRequestCreate: true
  • No labels
Copyright © 2022 JFrog Ltd.