Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

סכימה של קובץ תצורת build

קובץ תצורה של build מכיל הוראות ל-Cloud Build לביצוע משימות על סמך המפרטים שלכם. לדוגמה, קובץ תצורת ה-build יכול להכיל הוראות ליצירה, לאריזה ולדחיפה של קובצי אימג' של Docker.

בדף הזה מוסבר על הסכימה של קובץ ההגדרות של Cloud Build. הוראות ליצירה ולשימוש בקובץ תצורת build זמינות במאמר יצירת קובץ תצורת build בסיסי.

המבנה של קובץ תצורת build

קובצי התצורה של הבנייה מבוססים על משאב Build של Cloud Build API.

אפשר לכתוב את קובץ הגדרות ה-build באמצעות תחביר YAML או JSON. אם אתם שולחים בקשות לבנייה באמצעות כלי HTTP של צד שלישי, כמו curl, אתם צריכים להשתמש בתחביר JSON.

קובץ תצורת build בנוי כך:

YAML

steps:
- name: string
  args: [string, string, ...]
  env: [string, string, ...]
  allowFailure: boolean
  allowExitCodes: [string (int64 format), string (int64 format), ...]
  dir: string
  id: string
  waitFor: [string, string, ...]
  entrypoint: string
  secretEnv: string
  volumes: object(Volume)
  timeout: string (Duration format)
  script: string
  automapSubstitutions: boolean
  results: object(Results)
- name: string
  ...
- name: string
  ...
timeout: string (Duration format)
queueTtl: string (Duration format)
logsBucket: string
options:
 env: [string, string, ...]
 secretEnv: string
 volumes: object(Volume)
 sourceProvenanceHash: enum(HashType)
 machineType: enum(MachineType)
 diskSizeGb: string (int64 format)
 substitutionOption: enum(SubstitutionOption)
 dynamicSubstitutions: boolean
 automapSubstitutions: boolean
 logStreamingOption: enum(LogStreamingOption)
 logging: enum(LoggingMode)
 defaultLogsBucketBehavior: enum(DefaultLogsBucketBehavior)
 pool: object(PoolOption)
 pubsubTopic: string
 requestedVerifyOption: enum(RequestedVerifyOption)
substitutions: map (key: string, value: string)
tags: [string, string, ...]
serviceAccount: string
secrets: object(Secret)
availableSecrets: object(Secrets)
artifacts: object(Artifacts)
  goModules: [object(GoModules), ...]
  mavenArtifacts: [object(MavenArtifact), ...]
  pythonPackages: [object(PythonPackage), ...]
  npmPackages: [object(npmPackage), ...]
images:
- [string, string, ...]

JSON

{
    "steps": [
    {
        "name": "string",
        "args": [
            "string",
            "string",
            "..."
        ],
        "env": [
            "string",
            "string",
            "..."
        ],
        "allowFailure": "boolean",
        "allowExitCodes: [
            "string (int64 format)",
            "string (int64 format)",
            "..."
        ],
        "dir": "string",
        "id": "string",
        "waitFor": [
            "string",
            "string",
            "..."
        ],
        "entrypoint": "string",
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "timeout": "string (Duration format)",
        "script" : "string",
        "automapSubstitutions" : "boolean",
        "results": "object(Results)"
    },
    {
        "name": "string"
        ...
    },
    {
        "name": "string"
        ...
    }
    ],
    "timeout": "string (Duration format)",
    "queueTtl": "string (Duration format)",
    "logsBucket": "string",
    "options": {
        "sourceProvenanceHash": "enum(HashType)",
        "machineType": "enum(MachineType)",
        "diskSizeGb": "string (int64 format)",
        "substitutionOption": "enum(SubstitutionOption)",
        "dynamicSubstitutions": "boolean",
        "automapSubstitutions": "boolean",
        "logStreamingOption": "enum(LogStreamingOption)",
        "logging": "enum(LoggingMode)"
        "defaultLogsBucketBehavior": "enum(DefaultLogsBucketBehavior)"
        "env": [
            "string",
            "string",
            "..."
        ],
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "pool": "object(PoolOption)"
        "requestedVerifyOption": "enum(RequestedVerifyOption)"
    },
    "substitutions": "map (key: string, value: string)",
    "tags": [
        "string",
        "string",
        "..."
    ],
    "serviceAccount": "string",
    "secrets": "object(Secret)",
    "availableSecrets": "object(Secrets)",
    "artifacts": "object(Artifacts)",
      "goModules": [object(GoModules), ...],
      "mavenArtifacts": ["object(MavenArtifact)", ...],
      "pythonPackages": ["object(PythonPackage)", ...],
      "npmPackages": ["object(npmPackage)", ...],
    "images": [
        "string",
        "string",
        "..."
    ]
}

כל אחד מהקטעים בקובץ התצורה של ה-build מגדיר חלק מהמשימה שרוצים ש-Cloud Build יבצע:

שלבי ההגדרה

שלב בנייה מציין פעולה שרוצים ש-Cloud Build יבצע. בכל שלב ב-build, ‏ Cloud Build מריץ קונטיינר של Docker כמופע של docker run. שלבי ה-build דומים לפקודות בסקריפט, ומאפשרים לכם לבצע הוראות שרירותיות ב-build. אם אתם יכולים לארוז כלי build בקונטיינר,‏ Cloud Build יכול להפעיל אותו כחלק מה-build. כברירת מחדל, Cloud Build מבצע את כל השלבים של בנייה באופן סדרתי באותה מכונה. אם יש לכם שלבים שאפשר להריץ במקביל, השתמשו באפשרות waitFor.

אפשר לכלול עד 300 שלבי build בקובץ התצורה.

משתמשים בשדה steps בקובץ הגדרות ה-build כדי לציין שלב build. קטע קוד שמציג את סוג ההגדרה שאפשר להגדיר בשדה steps:

YAML

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/mydepl', 'my-image=gcr.io/my-project/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east4-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image"
            "deployment/mydepl"
            "my-image=gcr.io/my-project/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east4-b",
            "CLOUDSDK_CONTAINER_CLUSTER=my-cluster"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

`name`

משתמשים בשדה name של שלב build כדי לציין cloud builder, שהוא קובץ אימג' של קונטיינר שמריץ כלים נפוצים. משתמשים ב-builder בשלב build כדי להריץ את המשימות.

בקטע הקוד הבא מוצגים שלבי build שקוראים ל-builders‏ bazel,‏ gcloud ו-docker:

YAML

steps:
- name: 'gcr.io/cloud-builders/bazel'
...

- name: 'gcr.io/cloud-builders/gcloud'
...

- name: 'gcr.io/cloud-builders/docker'
...

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/bazel"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/gcloud"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/docker"
        ...
    }
    ]
}

`args`

השדה args של שלב בנייה מקבל רשימה של ארגומנטים ומעביר אותם לכלי הבנייה שאליו מתייחס השדה name. הארגומנטים שמועברים ל-Builder מועברים לכלי שפועל ב-Builder, וכך אפשר להפעיל כל פקודה שהכלי תומך בה. אם ל-builder שבו נעשה שימוש בשלב הבנייה יש entrypoint, הארגומנטים ישמשו כארגומנטים ל-entrypoint הזה. אם ה-builder לא מגדיר נקודת כניסה, הרכיב הראשון ב-args ישמש כנקודת כניסה, והשאר ישמש כארגומנטים.

אפשר ליצור עד 100 ארגומנטים לכל שלב. האורך המקסימלי של הארגומנט הוא 10,000 תווים.

קטע הקוד הבא מפעיל את הפקודה docker build ומתקין את התלויות של Maven:

YAML

steps:
- name: 'gcr.io/cloud-builders/mvn'
  args: ['install']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/mvn",
        "args": [
            "install"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

`env`

השדה env של שלב build מקבל רשימה של משתני סביבה שישמשו להרצת השלב. המשתנים הם בפורמט KEY=VALUE.

בהגדרת ה-build הבאה, השדה env של שלב ה-build מגדיר את האזור של Compute Engine ואת אשכול GKE לפני ההפעלה של kubectl:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/myimage', 'frontend=gcr.io/myproject/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east1-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image",
            "deployment/myimage",
            "frontend=gcr.io/myproject/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east1-b",
            "CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster"
        ]
    }
    ]
}

`allowFailure`

בשלב בנייה, אם מגדירים את הערך של השדה allowFailure ל-true, ושלב הבנייה נכשל, הבנייה תצליח כל עוד כל שאר שלבי הבנייה באותה בנייה יצליחו.

אם כל שלבי ה-build ב-build מסוים מוגדרים עם allowFailure כ-true וכל שלבי ה-build נכשלים, הסטטוס של ה-build עדיין יהיה Successful.

הערך של allowExitCodes מקבל עדיפות על פני השדה הזה.

קטע הקוד הבא מאפשר לבנות את התוכנה גם אם השלב הראשון נכשל:

YAML

steps:
- name: 'ubuntu'
  args: [ '-c', 'exit 1']
  allowFailure: true
- name: 'ubuntu'
  args: ['echo', 'Hello World']

JSON

{
  "steps": [
    {
        "name": "ubuntu",
        "args": [
            "-c",
            "exit -1"
        ],
        "allowFailure": true,
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "Hello World"
        ]
    }
  ]
}

`allowExitCodes`

משתמשים בשדה allowExitCodes כדי לציין שאפשר להתעלם מכשל בשלב בנייה אם השלב הזה מחזיר קוד יציאה מסוים.

אם שלב בנייה נכשל עם קוד יציאה שתואם לערך שסיפקתם ב-allowExitCodes, ‏ Cloud Build יאפשר לשלב הבנייה הזה להיכשל בלי שהבנייה כולה תיכשל.

אם 100% משלבי ה-build נכשלים, אבל כל שלב יוצא עם קוד שציינתם בשדה allowExitCodes, ה-build עדיין מצליח.

עם זאת, אם שלב ה-Build נכשל ונוצר קוד יציאה אחר – שלא תואם לערך שציינתם ב-allowExitCodes – ה-Build הכולל ייכשל.

קודי היציאה שרלוונטיים לבנייה תלויים בתוכנה שלכם. לדוגמה, '1' הוא קוד יציאה נפוץ ב-Linux. אפשר גם להגדיר קודי יציאה משלכם בסקריפטים. בשדה allowExitCodes אפשר להזין מספרים עד 255.

השדה הזה מקבל עדיפות על פני allowFailure.

קטע הקוד הבא מאפשר לבנייה להצליח אם השלב הראשון נכשל עם אחד מקודי היציאה שצוינו:

YAML

steps:
- name: 'ubuntu'
  args: ['-c', 'exit 1']
  allowExitCodes: [1]
- name: 'ubuntu'
  args: ['echo', 'Hello World']

JSON

{
  "steps": [
    {
        "name": "ubuntu",
        "args": [
            "-c",
            "exit 1"
        ],
        "allowExitCodes": [1],
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "Hello World"
        ]
    }
  ]
}

`dir`

משתמשים בשדה dir בשלב בנייה כדי להגדיר ספריית עבודה שתשמש להרצת הקונטיינר של השלב. אם מגדירים את השדה dir בשלב הבנייה, ספריית העבודה מוגדרת ל-/workspace/<dir>. אם הערך הזה הוא נתיב יחסי, הוא יחסי לספריית העבודה של ה-build. אם הערך הזה הוא מוחלט, יכול להיות שהוא מחוץ לספריית העבודה של הבנייה. במקרה כזה, יכול להיות שהתוכן של הנתיב לא יישמר בין ההפעלות של שלבי הבנייה (אלא אם מצוין נפח עבור הנתיב הזה).

בקטע הקוד הבא מוגדרת ספריית העבודה של שלב הבנייה כ-/workspace/examples/hello_world:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
  env: ['PROJECT_ROOT=hello']
  dir: 'examples/hello_world'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ],
        "env": [
            "PROJECT_ROOT=hello"
        ],
        "dir": "examples/hello_world"
    }
    ]
}

מזהה

משתמשים בשדה id כדי להגדיר מזהה ייחודי לשלב בנייה. השדה id משמש עם השדה waitFor כדי להגדיר את הסדר שבו שלבי ה-build יפעלו. הוראות לשימוש ב-waitFor וב-id מופיעות במאמר הגדרת הסדר של שלבי ה-build.

`waitFor`

משתמשים בשדה waitFor בשלב בנייה כדי לציין אילו שלבים צריכים לפעול לפני הפעלת שלב הבנייה. אם לא מספקים ערכים ל-waitFor, שלב הבנייה ממתין להשלמה מוצלחת של כל שלבי הבנייה הקודמים בבקשת הבנייה לפני שהוא מופעל. הוראות לשימוש ב-waitFor וב-id זמינות במאמר הגדרת הסדר של שלבי ה-build.

`entrypoint`

משתמשים ב-entrypoint בשלב בנייה כדי לציין נקודת כניסה אם לא רוצים להשתמש בנקודת הכניסה שמוגדרת כברירת מחדל בכלי הבנייה. אם לא מגדירים את השדה הזה, Cloud Build ישתמש בנקודת הכניסה של כלי ה-Builder. בקטע הקוד הבא מוגדרות נקודות הכניסה לשלב הבנייה של npm:

YAML

steps:
- name: 'gcr.io/cloud-builders/npm'
  entrypoint: 'node'
  args: ['--version']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/npm",
        "entrypoint": "node",
        "args": [
            "--version"
        ]
    }
    ]
}

`secretEnv`

רשימה של משתני סביבה שמוצפנים באמצעות מפתח קריפטוגרפי של Cloud KMS. צריך לציין את הערכים האלה בסודות של ה-build. מידע על השימוש בשדה הזה מופיע במאמר שימוש במשתנה מוצפן בבקשות build.

`volumes`

נפח הוא נפח של קונטיינר Docker שנטען בשלבי build כדי לשמור קבצים בין שלבי build. כש-Cloud Build מפעיל שלב build, הוא מבצע באופן אוטומטי mount של נפח workspace אל /workspace. אפשר לציין עוד אמצעי אחסון להרכבה במאגרי הצעדים שלכם באמצעות השדה volumes של הצעדים.

לדוגמה, קובץ תצורת ה-build הבא כותב קובץ לנפח בשלב הראשון וקורא אותו בשלב השני. אם בשלבים האלה לא צוין /persistent_volume path כנפח אחסון קבוע, בשלב הראשון הקובץ ייכתב בנתיב הזה, ואז הוא יימחק לפני הביצוע של השלב השני. אם מציינים את הנפח עם אותו שם בשני השלבים, התוכן של /persistent_volume בשלב הראשון נשמר בשלב השני.

YAML

steps:
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
        echo "Hello, world!" > /persistent_volume/file
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  args: ['cat', '/persistent_volume/file']

JSON

  {
    "steps": [
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "entrypoint": "bash",
        "args": [
          "-c",
          "echo \"Hello, world!\" > /persistent_volume/file\n"
        ]
      },
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "args": [
          "cat",
          "/persistent_volume/file"
        ]
     }
    ]
  }

`timeout`

משתמשים בשדה timeout בשלב בנייה כדי להגדיר מגבלת זמן לביצוע השלב. אם לא מגדירים את השדה הזה, השלב יפעל עד שהוא יושלם או עד שזמן הבנייה יסתיים. הערך בשדה timeout של שלב בנייה לא יכול להיות גדול מהערך של timeout שמוגדר לבנייה.

הערך timeout מצוין בשניות (בפורמט Duration) עם עד תשע ספרות אחרי הנקודה העשרונית, ומסתיים ב-s (לדוגמה: 3.5s).

בהגדרת ה-build הבאה, שלב ubuntu מגיע לזמן קצוב לתפוגה אחרי 500 שניות:

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
  timeout: 500s
- name: 'ubuntu'
  args: ['echo', 'hello world, after 600s']

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ],
        "timeout": "500s"
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello world, after 600s"
        ]
    }
    ]
}

סקריפט

משתמשים בשדה script בשלב בנייה כדי לציין סקריפט מעטפת להפעלה בשלב. אם מציינים script בשלב בנייה, אי אפשר לציין args או entrypoint באותו שלב. הוראות לשימוש בשדה script מופיעות במאמר הרצת סקריפטים של Bash.

automapSubstitutions

אם המשתנה מוגדר ל-true, כל ההחלפות ממופות אוטומטית וזמינות כמשתני סביבה בפעולה אחת. אם הערך הוא false, המערכת מתעלמת מהחלפות בשלב הזה. דוגמאות אפשר לראות במאמר בנושא החלפת ערכי משתנים.

תוצאות

ההרשאה מאפשרת לשלב בנייה לאחסן נתונים ואז לצרף את הנתונים האלה לאישור בתוצאות הבנייה אחרי שהבנייה מסתיימת. הנתונים המאוחסנים חייבים להיות צמד מפתח-ערך, כאשר המפתח הוא מחרוזת והערך הוא אובייקט JSON. תוצאה חייבת לכלול את השדות הבאים:

‫name: השם של התוצאה. השם הזה מופיע באישור שמתקבל בתוצאות הבנייה. אפשר גם להשתמש בשם הזה כדי להפנות לתוצאה בשלב בנייה. לדוגמה, אפשר להוסיף ערכים לתוצאה באמצעות script באותו שלב בנייה.
‫attestationContent: (אופציונלי) שם האישור. הערך יכול להיות כל ערך, והוא יופיע באישור שיתקבל בתוצאות הבנייה. השדה הזה נדרש רק אם אתם מתכננים לאמת את הצהרות הבנייה.
‫attestationType: (אופציונלי) סוג האישור. הערך יכול להיות כל ערך, והוא יופיע באישור שיתקבל בתוצאות הבנייה. השדה הזה נדרש רק אם אתם מתכננים לאמת את הצהרות הבנייה.

ב-build הבא נעשה שימוש בהגדרת תוצאה כדי ליצור אישור שמאפשר למשתמשים לוודא שב-build נעשה שימוש רק בכתובות URL עם קידומות נתמכות כדי ליצור את האימג'. בדוגמה הזו, התוצאה מוגדרת כ-allowlisted_prefixes. לאחר מכן, allowlisted_prefixes מוגדר כצמד מפתח/ערך של allowlisted_prefixes ושל [\"github.com\", \"gitlab.com\"], והוא מצורף כאישור לתוצאות הבנייה.

YAML

steps:
- name: "gcr.io/cloud-builders/docker"
  id: "build-step"
  args: ["build", "-t", "us-docker.pkg.dev/my-project/demo/helloworld-image", "."]
- name: "ubuntu"
  id: "check-source-fetch-urls"
  results:
    - name: "allowlisted_prefixes"
      attestationContent: "remote_fetch_allow_list"
      attestationType: "https://cloudbuild.googleapis.com/attestations/build_content_restrictions"
  script: |
    #!/bin/bash
    prefixes="[\"github.com\", \"gitlab.com\"]"
    echo "allowlisted_prefixes=$prefixes" >> $RESULTS
    cat $RESULTS
images:
  - "us-docker.pkg.dev/my-project/demo/helloworld-image"
options:
  requested_verify_option: VERIFIED
  defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "id": "build-step",
      "args": [
        "build",
        "-t",
        "us-docker.pkg.dev/my-project/demo/helloworld-image",
        "."
      ]
    },
    {
      "name": "ubuntu",
      "id": "check-source-fetch-urls",
      "results": [
        {
          "name": "allowlisted_prefixes",
          "attestationContent": "remote_fetch_allow_list",
          "attestationType": "https://cloudbuild.googleapis.com/attestations/build_content_restrictions"
        }
      ],
      "script": "#!/bin/bash\nprefixes=\"[\\\"github.com\\\", \\\"gitlab.com\\\"]\"\necho \"allowlisted_prefixes=$prefixes\" >> $RESULTS\ncat $RESULTS\n"
    }
  ],
  "images": [
    "us-docker.pkg.dev/my-project/demo/helloworld-image"
  ],
  "options": {
    "requested_verify_option": "VERIFIED",
    "defaultLogsBucketBehavior": "REGIONAL_USER_OWNED_BUCKET"
  }
}

`timeout`

משתמשים בשדה timeout מחוץ לשלב build כדי להגדיר את מגבלת הזמן הכוללת להרצת ה-build. אם הזמן הזה חולף, העבודה על ה-build נעצרת וסטטוס ה-build הוא TIMEOUT.

אם לא מגדירים את timeout, המערכת משתמשת בערך ברירת המחדל של timeout שהוא 60 דקות. הערך המקסימלי של timeout הוא 24 שעות. הערך timeout מצוין בשניות, בפורמט Duration, עם עד תשע ספרות אחרי הנקודה, ומסתיים ב-s (לדוגמה: 3.5s).

בקטע הקוד הבא, הערך של timeout מוגדר ל-660 שניות כדי למנוע מצב שבו ה-build יפסיק לפעול בגלל חוסר פעילות:

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
timeout: 660s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ]
    }
    ],
    "timeout": "660s"
}

`queueTtl`

משתמשים בשדה queueTtl כדי לציין את משך הזמן שבו אפשר להוסיף את ה-build לתור. אם בנייה נמצאת בתור יותר זמן מהערך שמוגדר ב-queueTtl, תוקף הבנייה פג וסטטוס הבנייה מוגדר ל-EXPIRED. אם לא מציינים ערך, Cloud Build משתמש בערך ברירת המחדל 3600s (שעה אחת). הספירה של queueTtl מתחילה ב-createTime. צריך לציין את queueTtl בשניות עם עד תשע ספרות אחרי הנקודה, ולסיים ב-s, לדוגמה, 3.5s.

בדוגמה הבאה, הערך timeout מוגדר ל-20s ו-queueTtl מוגדר ל-10s. השעון של queueTtl מתחיל לתקתק ב-createTime, שזה הזמן שבו נשלחה הבקשה לבנייה, והשעון של timeout מתחיל לתקתק ב-startTime, שזה הזמן שבו הבנייה מתחילה. לכן, תוקף המינוי של queueTtl יפוג בתאריך createTime + 10s אלא אם תהליך הבנייה יתחיל לפני כן.

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '5']
timeout: 20s
queueTtl: 10s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "5"
        ]
    }
    ],
    "timeout": "20s",
    "queueTtl": "10s"
}

`logsBucket`

מגדירים את השדה logsBucket של build כדי לציין קטגוריה של Cloud Storage שבה צריך לכתוב את יומני ה-build. אם לא מגדירים את השדה הזה, Cloud Build משתמש בערך של defaultLogsBucketBehavior כדי לאחסן את יומני הבנייה בקטגוריה שנוצרה על ידי Cloud Build ב-Cloud Storage.

בקטע הקוד הבא מוגדר ש-Cloud Build ישמור את יומני ה-build בקטגוריה מותאמת אישית ב-Cloud Storage.

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
logsBucket: 'gs://mybucket'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "logsBucket": "gs://mybucket"
}

`options`

בשדה options מציינים את הארגומנטים האופציונליים הבאים ל-build:

‫enableStructuredLogging: ההגדרה הזו מאפשרת מיפוי של שדות ספציפיים ביומן הבנייה לשדות של LogEntry כשיומן הבנייה נשלח אל Logging. לדוגמה, אם יומן הבנייה מכיל את התו message, ההודעה תופיע ביומן בפורמט textPayload או jsonPayload.message. שדות של יומן הרישום שלא ניתן למפות מופיעים ברשומה ביומן jsonPayload. מידע נוסף זמין במאמר בנושא מיפוי שדות של יומן build לשדות של רשומת יומן.

‫env: רשימה של הגדרות משתני סביבה גלובליים שיהיו קיימים בכל שלבי ה-build ב-build הזה. אם משתנה מוגדר גם ברמה הגלובלית וגם בשלב build, המשתנה ישתמש בערך של שלב ה-build. האלמנטים הם מהצורה KEY=VALUE כשמשתנה הסביבה KEY מקבל את הערך VALUE.

‫secretEnv: רשימה של משתני סביבה גלובליים, מוצפנים באמצעות מפתח קריפטוגרפי של Cloud Key Management Service, שיהיו זמינים לכל שלבי הבנייה בבנייה הזו. צריך לציין את הערכים האלה ב-Secret של הגרסה.

‫volumes: רשימה של אמצעי אחסון להרכבה גלובלית לכל שלבי הבנייה. כל נפח אחסון נוצר כנפח אחסון ריק לפני תחילת תהליך ה-build. בסיום הבנייה, אמצעי האחסון והתוכן שלהם מושלכים. שמות ונתיבים של נפחים גלובליים לא יכולים להתנגש עם הנפחים שמוגדרים בשלב בנייה. השימוש בנפח גלובלי ב-build עם שלב אחד בלבד לא תקין, כי הוא מציין בקשת build עם הגדרה שגויה.

pubsubTopic: אפשרות לציין שם של נושא Pub/Sub לקבלת התראות על סטטוס הבנייה. אם לא מציינים שם, Cloud Build משתמש בשם הנושא שמוגדר כברירת מחדל, cloud-builds. בקטע הקוד הבא מצוין ששם הנושא ב-Pub/Sub הוא my-topic:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
    pubsubTopic: 'projects/my-project/topics/my-topic'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "pubsubTopic": "projects/my-project/topics/my-topic"
    }
}

‫sourceProvenanceHash: מגדירים את האפשרות sourceProvenanceHash כדי לציין את אלגוריתם הגיבוב (hash) של מקור השושלת. בקטע הקוד הבא מצוין שאלגוריתם הגיבוב הוא SHA256:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
    sourceProvenanceHash: ['SHA256']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "sourceProvenanceHash": ["SHA256"]
    }
}

‫machineType: ב-Cloud Build יש ארבעה סוגים של מכונות וירטואליות עם CPU גבוה להרצת בנייה: שני סוגי מכונות עם 8 יחידות CPU ושני סוגי מכונות עם 32 יחידות CPU. ב-Cloud Build יש גם שני סוגים נוספים של מכונות וירטואליות עם CPU אחד ו-2 CPUs להרצת הבנייה. סוג המכונה שמוגדר כברירת מחדל הוא e2-standard-2 עם 2 מעבדים. בקשה למכונה וירטואלית עם מעבד חזק עלולה להאריך את זמן ההפעלה של ה-build. מוסיפים את האפשרות machineType כדי לבקש מכונה וירטואלית עם מעבד חזק יותר:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 machineType: 'E2_HIGHCPU_8'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    ],
    "options": {
        "machineType": "E2_HIGHCPU_8"
    }
}

מידע נוסף על השימוש באפשרות machineType זמין במאמר האצת תהליכי בנייה.

‫diskSizeGb: אפשר להשתמש באפשרות diskSizeGb כדי לבקש גודל דיסק מותאם אישית בשביל ה-build. הגודל המקסימלי שאפשר לבקש הוא 4,000GB.

בקטע הקוד הבא מוצגת בקשה לגודל דיסק של 200GB:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 diskSizeGb: '200'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "diskSizeGb": '200'
    }
}

‫logStreamingOption: האפשרות הזו מאפשרת לציין אם רוצים להזרים את יומני הבנייה ל-Cloud Storage. כברירת מחדל, Cloud Build אוסף יומני בנייה עם השלמת הבנייה. האפשרות הזו מציינת אם רוצים להזרים את יומני הבנייה בזמן אמת במהלך תהליך build. בקטע הקוד הבא מצוין שיומני ה-build מועברים בסטרימינג אל Cloud Storage:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
options:
 logStreamingOption: STREAM_ON

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "options": {
        "logStreamingOption": "STREAM_ON"
    }
}

‫ ‫logging: משתמשים באפשרות הזו כדי לציין אם רוצים לאחסן את יומני הבנייה ב-Cloud Logging או ב-Cloud Storage:

‫GCS_ONLY: יומני Build נשלחים לקטגוריות של Cloud Storage.
‫CLOUD_LOGGING_ONLY: יומני הבנייה נשלחים לקטגוריות ביומן ב-Logging.
‫LEGACY: יומני הבנייה נשלחים לקטגוריות בשני המיקומים. אם logging לא מוגדר, Cloud Build משתמש בערך הזה.
‫NONE: יומני הבנייה לא נשמרים.

מידע נוסף על היתרונות והשיקולים של אחסון יומני build זמין במאמר אפשרויות לאחסון יומני build.

בקטע הקוד הבא מצוין שיומני הבנייה מאוחסנים ב-Cloud Storage:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 logging: GCS_ONLY

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "logging": "GCS_ONLY"
    }
}

defaultLogsBucketBehavior:

משתמשים בשדה הזה כשמגדירים את logging לשליחת יומני הבנייה ל-Cloud Storage.

אם הערך של logging הוא GCS_ONLY, ‏ Legacy או לא מוגדר, יומני הבנייה נשלחים לקטגוריות ב-Cloud Storage. במקרה כזה, Cloud Build מעריך את השדות logsBucket ו-defaultLogsBucketBehavior כדי לקבוע לאיזו קטגוריה של Cloud Storage יועברו יומני הבנייה:

`logsBucket`	`defaultLogsBucketBehavior`	איפה מאוחסנים יומני הבנייה
צוינה קטגוריה	המערכת התעלמה מהערך	בקטגוריה שצוינה ב-`logsBucket`
ללא ערך	`REGIONAL_USER_OWNED_BUCKET`	בקטגוריה שנוצרה על ידי Cloud Build ושנמצאת בבעלות המשתמש
ללא ערך	`LEGACY_BUCKET`	בקטגוריה שנוצרה על ידי Cloud Build ושנמצאת בבעלותו Google Cloud

מידע נוסף זמין במאמר בנושא אפשרויות אחסון של יומני בנייה.

הגדרת ה-build הבאה מגדירה את השדה defaultLogsBucketBehavior לערך REGIONAL_USER_OWNED_BUCKET:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/myproject/myrepo/myimage', '.' ]
options:
  defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "-t",
        "us-central1-docker.pkg.dev/myproject/myrepo/myimage",
        "."
      ]
    }
    ],
    "options": {
      "defaultLogsBucketBehavior": "REGIONAL_USER_OWNED_BUCKET"
    }
}

‫dynamicSubstitutions: משתמשים באפשרות הזו כדי להפעיל או להשבית באופן מפורש הרחבת פרמטרים של bash בהחלפות. אם ה-build מופעל על ידי טריגר, השדה dynamicSubstitutions תמיד מוגדר כ-true ואין צורך לציין אותו בקובץ ההגדרות של ה-build. אם ההפעלה של ה-build מתבצעת באופן ידני, צריך להגדיר את השדה dynamicSubstitutions כ-true כדי שהרחבות של פרמטרים ב-bash יפורשו בזמן הפעלת ה-build.

‫automapSubstitutions: מיפוי אוטומטי של כל ההחלפות למשתני סביבה שיהיו זמינים לאורך כל ה-build. דוגמאות אפשר לראות במאמר בנושא החלפת ערכים של משתנים.

‫substitutionOption: מגדירים את האפשרות הזו יחד עם השדה substitutions שבהמשך כדי לציין את ההתנהגות במקרה של שגיאה בבדיקות ההחלפה.

‫pool: מגדירים את הערך של השדה הזה לשם המשאב של המאגר הפרטי כדי להפעיל את הבנייה. הוראות להפעלת בנייה במאגר פרטי מפורטות במאמר הפעלת בנייה במאגר פרטי.

‫requestedVerifyOption: מגדירים את הערך של requestedVerifyOption ל-VERIFIED כדי להפעיל ולאמת את היצירה של אישורים ושל מטא-נתונים של מקור עבור הבנייה. אחרי ההגדרה, ה-builds יסומנו בסטטוס SUCCESS רק אם ייווצרו אישורים ונתוני מקור.

`substitutions`

אפשר להשתמש בהחלפות בקובץ התצורה של ה-build כדי להחליף משתנים ספציפיים בזמן ה-build. החלפות שימושיות למשתנים שהערך שלהם לא ידוע עד משך זמן של תהליך build, או לשימוש חוזר בבקשת build קיימת עם ערכים שונים של משתנים. כברירת מחדל, אם חסר משתנה החלפה או החלפה, ה-build מחזיר שגיאה. אבל אתם יכולים להשתמש באפשרות ALLOW_LOOSE כדי לדלג על הבדיקה הזו.

בקטע הקוד הבא נעשה שימוש בהחלפות כדי להדפיס את המחרוזת hello world. האפשרות להחלפה ALLOW_LOOSE מוגדרת, כלומר גרסת ה-build לא תחזיר שגיאה אם חסר משתנה החלפה או אם חסרה החלפה.

YAML

steps:
- name: 'ubuntu'
  args: ['echo', 'hello ${_SUB_VALUE}']
substitutions:
    _SUB_VALUE: world
options:
    substitution_option: 'ALLOW_LOOSE'

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello ${_SUB_VALUE}"
        ]
    }
    ],
    "substitutions": {
        "_SUB_VALUE": "world"
},
    "options": {
        "substitution_option": "ALLOW_LOOSE"
    }
}

הוראות נוספות לשימוש ב-substitutions מפורטות במאמר החלפת ערכים של משתנים.

`tags`

אפשר להשתמש בשדה tags כדי לארגן את הגרסאות לקבוצות וכדי לסנן את הגרסאות. ההגדרה הבאה מגדירה שני תגים בשמות mytag1 ו-mytag2:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  ...
- name: 'ubuntu'
  ...
tags: ['mytag1', 'mytag2']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker"
    },
    {
        "name": "ubuntu"
    }
    ],
    "tags": [
        "mytag1",
        "mytag2"
    ]
}

`availableSecrets`

משתמשים בשדה הזה כדי להשתמש בסוד מ-Secret Manager עם Cloud Build. מידע נוסף מפורט במאמר שימוש בסודות.

`secrets`

‫Secret משייך קבוצה של משתני סביבה סודיים שמכילים ערכים מוצפנים למפתח Cloud KMS שבו יש להשתמש כדי לפענח את הערך.

`serviceAccount`

משתמשים בשדה הזה כדי לציין את חשבון השירות של IAM שבו רוצים להשתמש בזמן הבנייה. מידע נוסף זמין במאמר הגדרת חשבונות שירות שצוינו על ידי המשתמש.

אי אפשר לציין בשדה הזה את חשבון השירות מדור קודם של Cloud Build.

`images`

השדה images בקובץ ההגדרות של ה-build מציין קובץ אימג' אחד או יותר של Linux Docker ש-Cloud Build צריך להעביר בדחיפה ל-Artifact Registry. יכול להיות שיש לכם גרסת build שמבצעת משימות בלי ליצור תמונות Linux Docker, אבל אם אתם יוצרים תמונות ולא מעלים אותן למאגר, התמונות נמחקות בסיום ה-build. אם תמונה שצוינה לא נוצרת במהלך ה-build, ה-build ייכשל. מידע נוסף על אחסון תמונות זמין במאמר אחסון ארטיפקטים ב-Artifact Registry.

הגדרת ה-build הבאה מגדירה את השדה images לאחסון האימג' שנוצר:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
images: ['gcr.io/myproject/myimage']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "images": [
        "gcr.io/myproject/myimage"
    ]
}

`artifacts`

השדה artifacts מציין פריט מידע אחד או יותר שייאוחסנו ב-Cloud Storage או ב-Artifact Registry אחרי שכל שלבי הבנייה יסתיימו בהצלחה.

`objects`

בשדה artifacts, השדה object מציין פריט מידע אחד או יותר לאחסון ב-Cloud Storage. מידע נוסף זמין במאמר בנושא אחסון של ארטיפקטים של בנייה ב-Cloud Storage.

הגדרת ה-build הבאה מגדירה את השדה artifacts לאחסון חבילת Go שנבנתה ב-gs://mybucket/:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['build', 'my-package']
artifacts:
  objects:
    location: 'gs://mybucket/'
    paths: ['my-package']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "build",
            "my-package"
        ]
    }
    ],
    "artifacts": {
      "objects": {
        "location": "gs://mybucket/",
        "paths": [
            "my-package"
        ]
      }
    }
}

`goModules`

השדה goModules מאפשר לכם להעלות מודולי Go שאינם קונטיינרים למאגרי Go ב-Artifact Registry. מידע נוסף זמין במאמר בנושא פיתוח ובדיקה של אפליקציות Go.

השדה repository_location מציין את מאגר Artifact Registry שבו יאוחסנו החבילות. בשדה module_path מציינים את הספרייה המקומית שמכילה את מודול Go להעלאה. הספרייה הזו חייבת להכיל קובץ go.mod.

מומלץ להשתמש בנתיב מוחלט לערך של module_path. אפשר להשתמש ב-. כדי להפנות לספריית העבודה הנוכחית, אבל אי אפשר להשמיט את השדה או להשאיר אותו ריק. הוראות נוספות לשימוש ב-module_path זמינות במאמר פיתוח ובדיקה של אפליקציות Go.

הגדרת ה-build הבאה מגדירה את השדה goModules להעלאת המודול ב-example.com/myapp למאגר Artifact Registry‏ quickstart-go-repo:

YAML

artifacts:
  goModules:
    - repositoryName: 'quickstart-go-repo'
      repositoryLocation: 'us-central1'
      repositoryProjectId: 'argo-local-myname'
      sourcePath: '/workspace/myapp'
      modulePath: 'example.com/myapp'
      moduleVersion: 'v1.0.0'

JSON

{
  "artifacts": {
    "goModules": [
     {
      "repositoryName": "quickstart-go-repo",
      "repositoryLocation": "us-central1",
      "repositoryProjectId": "argo-local-myname",
      "sourcePath": "/workspace/myapp",
      "modulePath": "example.com/myapp",
      "moduleVersion": "v1.0.0"
     }
    ]
  }
}

`mavenArtifacts`

בשדה mavenArtifacts אפשר להעלות ארטיפקטים של Java שאינם קונטיינרים למאגרי Maven ב-Artifact Registry. מידע נוסף זמין במאמר פיתוח ובדיקה של אפליקציות Java.

דוגמה: העלאה של כל קובצי Maven בתיקייה למאגר ב-Artifact Registry

הגדרת ה-build הבאה מגדירה את השדה mavenArtifacts להעלאת כל הקבצים בתיקייה /workspace/target/com/mycompany/app/my-app-1/1.0.0/ למאגר https://us-central1-maven.pkg.dev/my-project-id/my-java-repo ב-Artifact Registry:

YAML

artifacts:
  mavenArtifacts:
    - repository: 'https://us-central1-maven.pkg.dev/my-project-id/my-java-repo'
      deployFolder: '/workspace/target'
      artifactId: 'my-app-1'
      groupId: 'com.mycompany.app'
      version: '1.0.0'

JSON

{
  "artifacts": {
    "mavenArtifacts": [
      {
        "repository": "https://us-central1-maven.pkg.dev/my-project-id/my-java-repo",
        "deployFolder": "/workspace/target",
        "artifactId": "my-app-1",
        "groupId": "com.mycompany.app",
        "version": "1.0.0"
      }
    ]
  }
}

כדי לפרוס את קובצי Maven אל /workspace/target/com/mycompany/app/my-app-1/1.0.0/, מוסיפים את האפשרות -DaltDeploymentRepository=local::default::file:./workspace/target לפקודת הפריסה של Maven.

דוגמה: העלאת קובץ Maven ארוז למאגר Artifact Registry

הגדרת ה-build הבאה מגדירה את השדה mavenArtifacts להעלאת הקובץ הארוז my-app-1.0-SNAPSHOT.jar למאגר https://us-central1-maven.pkg.dev/my-project-id/my-java-repo ב-Artifact Registry:

YAML

artifacts:
  mavenArtifacts:
    - repository: 'https://us-central1-maven.pkg.dev/my-project-id/my-java-repo'
      path: '/workspace/my-app/target/my-app-1.0-SNAPSHOT.jar'
      artifactId: 'my-app-1'
      groupId: 'com.mycompany.app'
      version: '1.0.0'

JSON

{
  "artifacts": {
    "mavenArtifacts": [
      {
        "repository": "https://us-central1-maven.pkg.dev/my-project-id/my-java-repo",
        "path": "/workspace/my-app/target/my-app-1.0-SNAPSHOT.jar",
        "artifactId": "my-app-1",
        "groupId": "com.mycompany.app",
        "version": "1.0.0"
      }
    ]
  }
}

`pythonPackages`

בשדה pythonPackages אפשר להעלות חבילות Python ל-Artifact Registry. מידע נוסף זמין במאמר פיתוח ובדיקה של אפליקציות Python.

הגדרת ה-build הבאה מגדירה את השדה pythonPackages להעלאת חבילת Python‏ dist/my-pkg.whl למאגר https://us-east1-python.pkg.dev/my-project/my-repo ב-Artifact Registry:

YAML

artifacts:
  pythonPackages:
   - repository: 'https://us-east1-python.pkg.dev/my-project/my-repo'
     paths: ['dist/my-pkg.whl']

JSON

{
  "artifacts": {
    "pythonPackages": [
      {
        "repository": "https://us-east1-python.pkg.dev/my-project/my-repo",
        "paths": ["dist/my-pkg.whl"]
      }
    ]
  }
}

`npmPackages`

משתמשים בשדה npmPackages כדי להגדיר את Cloud Build להעלאת חבילות npm שנוצרו למאגרים נתמכים ב-Artifact Registry. חובה לציין ערכים עבור repository ו-packagePath.

בשדה repository מציינים את מאגר Artifact Registry שבו רוצים לאחסן את החבילות. השדה packagePath מציין את הספרייה המקומית שמכילה את חבילת ה-npm להעלאה. הספרייה הזו חייבת להכיל קובץ package.json.

מומלץ להשתמש בנתיב מוחלט לערך של packagePath. אפשר להשתמש ב-. כדי להפנות לספריית העבודה הנוכחית, אבל אי אפשר להשמיט את השדה או להשאיר אותו ריק. הוראות נוספות לשימוש ב-npmPackages זמינות במאמר בנייה ובדיקה של אפליקציות Node.js.

הגדרת ה-build הבאה מגדירה את השדה npmPackages להעלאת חבילת npm בספרייה /workspace/my-pkg למאגר Artifact Registry‏ https://us-east1-npm.pkg.dev/my-project/my-repo.

YAML

artifacts:
  npmPackages:
   - repository: 'https://us-east1-npm.pkg.dev/my-project/my-repo'
     packagePath: '/workspace/my-pkg'

JSON

{
  "artifacts": {
    "npmPackages": [
      {
        "repository": "https://us-east1-npm.pkg.dev/my-project/my-repo",
        "packagePath": "/workspace/my-pkg"
      }
    ]
  }
}

`oci`

משתמשים בשדה oci כדי להגדיר את Cloud Build להעלאה של קובצי OCI למאגרים נתמכים ב-Artifact Registry. חובה לציין ערכים עבור file ו-registryPath.

בשדה registryPath מציינים את מאגר Artifact Registry שבו רוצים לאחסן את התמונות. בשדה file מציינים את הספרייה המקומית שמכילה את תמונת ה-OCI להעלאה. הספרייה הזו חייבת להכיל קובץ תמונה של OCI.

מומלץ להשתמש בנתיב מוחלט לערך של file. אפשר להשתמש ב-. כדי להפנות לספריית העבודה הנוכחית, אבל אי אפשר להשמיט את השדה או להשאיר אותו ריק.

הגדרת ה-build הבאה מגדירה את השדה oci להעלאת תמונת ה-OCI בספרייה /.pack/layout-repo/my-app למאגר Artifact Registry‏ https://us-east1-docker.pkg.dev/my-project/my-repo.

YAML

artifacts:
  oci:
  - file: '/.pack/layout-repo/my-app'
    registryPath: 'https://us-east1-docker.pkg.dev/my-project/my-repo'
    tags: ["primary_image"]

JSON

{
  "artifacts": {
    "oci": [
      {
        "file": "/.pack/layout-repo/my-app",
        "registryPath": "https://us-east1-docker.pkg.dev/my-project/my-repo",
        "tags": ["primary_image"]
      }
    ]
  }
}

`genericArtifacts`

משתמשים בשדה genericArtifacts כדי להעלות קבצים עם סוגים לא מוגדרים כחבילה חדשה במאגר כללי ב-Artifact Registry. ההגדרה הזו שימושית אם רוצים להעלות קבצים גנריים כמו קובצי טקסט או קבצים בינאריים, או אם רוצים להעלות חבילה שהיא לא סוג מאגר נתמך ב-Artifact Registry.

השדה folder מציין את התיקייה שמכילה את הקבצים שרוצים להעלות למאגר הכללי. השדה registryPath הוא הכתובת של מאגר Artifact Registry כללי שמקבל את הקבצים מהתיקייה שלכם.

הגדרת ה-build הבאה מגדירה את השדה genericArtifacts להעלאת התיקייה /workspace/binaryOut למאגר הכללי projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version ב-Artifact Registry.

YAML

artifacts:
  genericArtifacts:
  - folder: '/workspace/binaryOut'
    registryPath: 'projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version'

JSON

{
  "artifacts": {
    "genericArtifacts": [
      {
        "folder": "/workspace/binaryOut",
        "registryPath": "projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version"
      }
    ]
  }
}

אתם יכולים להגדיר ארטיפקט כללי כתלות ב-build, כך ש-Cloud Build יוריד את התלות לפני שה-build יתחיל. מידע נוסף זמין במאמר Specify a generic artifact as a dependency.

שימוש בקובצי Dockerfile

אם אתם מריצים בניית Docker ב-Cloud Build באמצעות ה-CLI של gcloud או טריגרים של בנייה, אתם יכולים להשתמש ב-Dockerfile בלי קובץ הגדרות בנייה נפרד. אם רוצים לבצע שינויים נוספים בגרסאות ה-build של Docker, אפשר לספק קובץ הגדרות של build בנוסף ל-Dockerfile. הוראות ליצירת קובץ אימג' של Docker באמצעות Dockerfile זמינות במאמר מדריך למתחילים: יצירה.

הרשת של Cloud Build

כש-Cloud Build מריץ כל שלב בבנייה, הוא מצרף את הקונטיינר של השלב לרשת Docker מקומית בשם cloudbuild. cloudbuildהמארחים ברשת כוללים Application Default Credentials‏ (ADC), ששירותי Google Cloud Google Cloud יכולים להשתמש בהם כדי למצוא אוטומטית את פרטי הכניסה שלכם. אם אתם מריצים קונטיינרים מוטמעים של Docker ורוצים לחשוף את ADC לקונטיינר בסיסי או להשתמש ב-gcloud בשלב docker, צריך להשתמש בדגל --network בשלב build של Docker:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '--network=cloudbuild', '.']

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "--network=cloudbuild",
        "."
      ]
   }
  ]
}

המאמרים הבאים

כאן מוסבר איך ליצור קובץ תצורה בסיסי של build כדי להגדיר את ה-builds ל-Cloud Build.
הוראות להפעלת גרסאות build ב-Cloud Build זמינות במאמר התחלת גרסת build באופן ידני.

סכימה של קובץ תצורת build קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

המבנה של קובץ תצורת build

YAML

JSON

שלבי ההגדרה

YAML

JSON

name

YAML

JSON

args

YAML

JSON

env

YAML

JSON

allowFailure

YAML

JSON

allowExitCodes

YAML

JSON

dir

YAML

JSON

מזהה

waitFor

entrypoint

YAML

JSON

secretEnv

volumes

YAML

JSON

timeout

YAML

JSON

סקריפט

automapSubstitutions

תוצאות

YAML

JSON

timeout

YAML

JSON

queueTtl

YAML

JSON

logsBucket

YAML

JSON

options

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

substitutions

YAML

JSON

tags

YAML

JSON

availableSecrets

secrets

serviceAccount

images

YAML

JSON

artifacts

objects

סכימה של קובץ תצורת build

`name`

`args`

`env`

`allowFailure`

`allowExitCodes`

`dir`

`waitFor`

`entrypoint`

`secretEnv`

`volumes`

`timeout`

`timeout`

`queueTtl`

`logsBucket`

`options`

`substitutions`

`tags`

`availableSecrets`

`secrets`

`serviceAccount`

`images`

`artifacts`

`objects`

`goModules`

`mavenArtifacts`

`pythonPackages`

`npmPackages`

`oci`

`genericArtifacts`