Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

3.4. Git source

When specified, source code is fetched from the supplied location.

If you supply an inline Dockerfile, it overwrites the Dockerfile in the contextDir of the Git repository.

The source definition is part of the spec section in the BuildConfig: 

source:
  git:
1 

    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir"
2 

  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"
3
Copy to Clipboard Toggle word wrap
1
The git field contains the URI to the remote Git repository of the source code. Optionally, specify the ref field to check out a specific Git reference. A valid ref can be a SHA1 tag or a branch name.
2
The contextDir field allows you to override the default location inside the source code repository where the build looks for the application source code. If your application exists inside a sub-directory, you can override the default location (the root folder) using this field.
3
If the optional dockerfile field is provided, it should be a string containing a Dockerfile that overwrites any Dockerfile that may exist in the source repository.

If the ref field denotes a pull request, the system uses a git fetch operation and then checkout FETCH_HEAD.

When no ref value is provided, OpenShift Container Platform performs a shallow clone (--depth=1). In this case, only the files associated with the most recent commit on the default branch (typically master) are downloaded. This results in repositories downloading faster, but without the full commit history. To perform a full git clone of the default branch of a specified repository, set ref to the name of the default branch (for example master).

警告

Git clone operations that go through a proxy that is performing man in the middle (MITM) TLS hijacking or reencrypting of the proxied connection do not work.

3.4.1. Using a proxy
复制链接

If your Git repository can only be accessed using a proxy, you can define the proxy to use in the source section of the build configuration. You can configure both an HTTP and HTTPS proxy to use. Both fields are optional. Domains for which no proxying should be performed can also be specified in the NoProxy field.

注意

Your source URI must use the HTTP or HTTPS protocol for this to work. 

source:
  git:
    uri: "https://github.com/openshift/ruby-hello-world"
    httpProxy: http://proxy.example.com
    httpsProxy: https://proxy.example.com
    noProxy: somedomain.com, otherdomain.com
Copy to Clipboard Toggle word wrap
注意

For Pipeline strategy builds, given the current restrictions with the Git plug-in for Jenkins, any Git operations through the Git plug-in do not leverage the HTTP or HTTPS proxy defined in the BuildConfig. The Git plug-in only uses the proxy configured in the Jenkins UI at the Plugin Manager panel. This proxy is then used for all git interactions within Jenkins, across all jobs.

Additional resources

  • You can find instructions on how to configure proxies through the Jenkins UI at JenkinsBehindProxy.

3.4.2. Source Clone Secrets
复制链接

Builder pods require access to any Git repositories defined as source for a build. Source clone secrets are used to provide the builder pod with access it would not normally have access to, such as private repositories or repositories with self-signed or untrusted SSL certificates.

The following source clone secret configurations are supported:

  • .gitconfig File
  • Basic Authentication
  • SSH Key Authentication
  • Trusted Certificate Authorities
注意

You can also use combinations of these configurations to meet your specific needs.

When a BuildConfig is created, OpenShift Container Platform can automatically populate its source clone secret reference. This behavior allows the resulting builds to automatically use the credentials stored in the referenced secret to authenticate to a remote Git repository, without requiring further configuration.

To use this functionality, a secret containing the Git repository credentials must exist in the namespace in which the BuildConfig is later created. This secrets must include one or more annotations prefixed with build.openshift.io/source-secret-match-uri-. The value of each of these annotations is a Uniform Resource Identifier (URI) pattern, which is defined as follows. When a BuildConfig is created without a source clone secret reference and its Git source URI matches a URI pattern in a secret annotation, OpenShift Container Platform automatically inserts a reference to that secret in the BuildConfig.

Prerequisites

A URI pattern must consist of:

  • A valid scheme: *://, git://, http://, https:// or ssh://
  • A host: *` or a valid hostname or IP address optionally preceded by *.
  • A path: /* or / followed by any characters optionally including * characters

In all of the above, a * character is interpreted as a wildcard.

重要

URI patterns must match Git source URIs which are conformant to RFC3986. Do not include a username (or password) component in a URI pattern.

For example, if you use ssh://git@bitbucket.atlassian.com:7999/ATLASSIAN jira.git for a git repository URL, the source secret must be specified as ssh://bitbucket.atlassian.com:7999/* (and not ssh://git@bitbucket.atlassian.com:7999/*). 

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'
Copy to Clipboard Toggle word wrap

Procedure

If multiple secrets match the Git URI of a particular BuildConfig, OpenShift Container Platform selects the secret with the longest match. This allows for basic overriding, as in the following example.

The following fragment shows two partial source clone secrets, the first matching any server in the domain mycorp.com accessed by HTTPS, and the second overriding access to servers mydev1.mycorp.com and mydev2.mycorp.com: 

kind: Secret
apiVersion: v1
metadata:
  name: matches-all-corporate-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
  ...

kind: Secret
apiVersion: v1
metadata:
  name: override-for-my-dev-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
  ...
Copy to Clipboard Toggle word wrap

  • Add a build.openshift.io/source-secret-match-uri- annotation to a pre-existing secret using: 

    $ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'
    Copy to Clipboard Toggle word wrap

3.4.2.2. Manually adding a source clone secret
复制链接

Source clone secrets can be added manually to a build configuration by adding a sourceSecret field to the source section inside the BuildConfig and setting it to the name of the secret that you created. In this example, it is the basicsecret. 

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
    git:
      uri: "https://github.com/user/app.git"
    sourceSecret:
      name: "basicsecret"
  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "python-33-centos7:latest"
Copy to Clipboard Toggle word wrap

Procedure

You can also use the oc set build-secret command to set the source clone secret on an existing build configuration.

  • To set the source clone secret on an existing build configuration, enter the following command: 

    $ oc set build-secret --source bc/sample-build basicsecret
    Copy to Clipboard Toggle word wrap

3.4.2.3. Creating a secret from a .gitconfig file
复制链接

If the cloning of your application is dependent on a .gitconfig file, then you can create a secret that contains it. Add it to the builder service account and then your BuildConfig.

Procedure

  • To create a secret from a .gitconfig file: 
$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>
Copy to Clipboard Toggle word wrap
注意

SSL verification can be turned off if sslVerify=false is set for the http section in your .gitconfig file: 

[http]
        sslVerify=false
Copy to Clipboard Toggle word wrap

If your Git server is secured with two-way SSL and user name with password, you must add the certificate files to your source build and add references to the certificate files in the .gitconfig file.

Prerequisites

  • You must have Git credentials.

Procedure

Add the certificate files to your source build and add references to the certificate files in the .gitconfig file.

  1. Add the client.crt, cacert.crt, and client.key files to the /var/run/secrets/openshift.io/source/ folder in the application source code.

  2. In the .gitconfig file for the server, add the [http] section shown in the following example: 

    # cat .gitconfig
    Copy to Clipboard Toggle word wrap

    Example output

    [user]
        name = <name>
        email = <email>
[http]
        sslVerify = false
        sslCert = /var/run/secrets/openshift.io/source/client.crt
        sslKey = /var/run/secrets/openshift.io/source/client.key
        sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crt
    Copy to Clipboard Toggle word wrap

  3. Create the secret: 

    $ oc create secret generic <secret_name> \
--from-literal=username=<user_name> \
    1 
    
--from-literal=password=<password> \
    2 
    
--from-file=.gitconfig=.gitconfig \
--from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \
--from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \
--from-file=client.key=/var/run/secrets/openshift.io/source/client.key
    Copy to Clipboard Toggle word wrap
    1
    The user’s Git user name.
    2
    The password for this user.
重要

To avoid having to enter your password again, be sure to specify the source-to-image (S2I) image in your builds. However, if you cannot clone the repository, you must still specify your user name and password to promote the build.

Additional resources

  • /var/run/secrets/openshift.io/source/ folder in the application source code.

Basic authentication requires either a combination of --username and --password, or a token to authenticate against the software configuration management (SCM) server.

Prerequisites

  • User name and password to access the private repository.

Procedure

  1. Create the secret first before using the --username and --password to access the private repository: 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --type=kubernetes.io/basic-auth
    Copy to Clipboard Toggle word wrap

  2. Create a basic authentication secret with a token: 

    $ oc create secret generic <secret_name> \
    --from-literal=password=<token> \
    --type=kubernetes.io/basic-auth
    Copy to Clipboard Toggle word wrap

SSH key based authentication requires a private SSH key.

The repository keys are usually located in the $HOME/.ssh/ directory, and are named id_dsa.pub, id_ecdsa.pub, id_ed25519.pub, or id_rsa.pub by default.

Procedure

  1. Generate SSH key credentials: 

    $ ssh-keygen -t ed25519 -C "your_email@example.com"
    Copy to Clipboard Toggle word wrap
    注意

    Creating a passphrase for the SSH key prevents OpenShift Container Platform from building. When prompted for a passphrase, leave it blank.

    Two files are created: the public key and a corresponding private key (one of id_dsa, id_ecdsa, id_ed25519, or id_rsa). With both of these in place, consult your source control management (SCM) system’s manual on how to upload the public key. The private key is used to access your private repository.

  2. Before using the SSH key to access the private repository, create the secret: 

    $ oc create secret generic <secret_name> \
    --from-file=ssh-privatekey=<path/to/ssh/private/key> \
    --type=kubernetes.io/ssh-auth
    Copy to Clipboard Toggle word wrap

The set of Transport Layer Security (TLS) certificate authorities (CA) that are trusted during a Git clone operation are built into the OpenShift Container Platform infrastructure images. If your Git server uses a self-signed certificate or one signed by an authority not trusted by the image, you can create a secret that contains the certificate or disable TLS verification.

If you create a secret for the CA certificate, OpenShift Container Platform uses it to access your Git server during the Git clone operation. Using this method is significantly more secure than disabling Git SSL verification, which accepts any TLS certificate that is presented.

Procedure

Create a secret with a CA certificate file.

  1. If your CA uses Intermediate Certificate Authorities, combine the certificates for all CAs in a ca.crt file. Enter the following command: 

    $ cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt
    Copy to Clipboard Toggle word wrap

    1. Create the secret: 

      $ oc create secret generic mycert --from-file=ca.crt=</path/to/file>
      1
      Copy to Clipboard Toggle word wrap
      1
      You must use the key name ca.crt.

3.4.2.8. Source secret combinations
复制链接

You can combine the different methods for creating source clone secrets for your specific needs.

You can combine the different methods for creating source clone secrets for your specific needs, such as a SSH-based authentication secret with a .gitconfig file.

Prerequisites

  • SSH authentication
  • .gitconfig file

Procedure

  • To create a SSH-based authentication secret with a .gitconfig file, run: 

    $ oc create secret generic <secret_name> \
    --from-file=ssh-privatekey=<path/to/ssh/private/key> \
    --from-file=<path/to/.gitconfig> \
    --type=kubernetes.io/ssh-auth
    Copy to Clipboard Toggle word wrap

You can combine the different methods for creating source clone secrets for your specific needs, such as a secret that combines a .gitconfig file and certificate authority (CA) certificate.

Prerequisites

  • .gitconfig file
  • CA certificate

Procedure

  • To create a secret that combines a .gitconfig file and CA certificate, run: 

    $ oc create secret generic <secret_name> \
    --from-file=ca.crt=<path/to/certificate> \
    --from-file=<path/to/.gitconfig>
    Copy to Clipboard Toggle word wrap

You can combine the different methods for creating source clone secrets for your specific needs, such as a secret that combines a basic authentication and certificate authority (CA) certificate.

Prerequisites

  • Basic authentication credentials
  • CA certificate

Procedure

  • Create a basic authentication secret with a CA certificate, run: 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=ca-cert=</path/to/file> \
    --type=kubernetes.io/basic-auth
    Copy to Clipboard Toggle word wrap

You can combine the different methods for creating source clone secrets for your specific needs, such as a secret that combines a basic authentication and .gitconfig file.

Prerequisites

  • Basic authentication credentials
  • .gitconfig file

Procedure

  • To create a basic authentication secret with a .gitconfig file, run: 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --type=kubernetes.io/basic-auth
    Copy to Clipboard Toggle word wrap

You can combine the different methods for creating source clone secrets for your specific needs, such as a secret that combines a basic authentication, .gitconfig file, and certificate authority (CA) certificate.

Prerequisites

  • Basic authentication credentials
  • .gitconfig file
  • CA certificate

Procedure

  • To create a basic authentication secret with a .gitconfig file and CA certificate, run: 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --from-file=ca-cert=</path/to/file> \
    --type=kubernetes.io/basic-auth
    Copy to Clipboard Toggle word wrap
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat