‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

אפשר לכתוב את קובץ תצורת ה-build באמצעות תחביר YAML או JSON. אם אתם שולחים בקשות build באמצעות כלי 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)
 workerRelease: string
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)",
        "pubsubTopic: string",
        "requestedVerifyOption": "enum(RequestedVerifyOption)",
        "workerRelease": "string"
    },
    "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 יבצע:

שלבי פיתוח

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

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

כדי לציין שלב build, משתמשים בשדה steps בקובץ התצורה של ה-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 שקוראים לכלים 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 של שלב build מקבל רשימה של ארגומנטים ומעביר אותם ל-builder שאליו מתייחס השדה name. הארגומנטים שמועברים לכלי ה-builder מועברים לכלי שפועל ב-builder, וכך אפשר להפעיל כל פקודה שהכלי תומך בה. אם לכלי שמשמש בשלב ה-build יש נקודת כניסה, המערכת תשתמש ב-args כארגומנטים לנקודת הכניסה הזו. אם ה-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`

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

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

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

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

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 כדי לציין שאפשר להתעלם משגיאה בשלב build אם השלב הזה מחזיר קוד יציאה מסוים.

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

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

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

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

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

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

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

בקטע הקוד הבא, ספריית העבודה של שלב ה-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 כדי להגדיר מזהה ייחודי לשלב build. השדה id משמש יחד עם השדה waitFor כדי להגדיר את הסדר שבו שלבי ה-build צריכים לפעול. הוראות לשימוש ב-waitFor וב-id מופיעות במאמר הגדרת הסדר של שלבי ה-build.

`waitFor`

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

`entrypoint`

אם אתם לא רוצים להשתמש בנקודת הכניסה שמוגדרת כברירת מחדל בכלי ה-build, אתם יכולים להשתמש ב-entrypoint בשלב ה-build כדי לציין נקודת כניסה. אם לא מגדירים את השדה הזה, Cloud Build ישתמש בנקודת הכניסה של ה-builder. בקטע הקוד הבא מוגדרות נקודות הכניסה לשלב ה-build של 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`

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

לדוגמה, קובץ תצורת ה-build הבא כותב קובץ לנפח בשלב הראשון וקורא אותו בשלב השני. אם בשלבים האלה לא צוין הנתיב /persistent_volume כנפח אחסון מתמיד, השלב הראשון יכתוב את הקובץ בנתיב הזה, ואז הקובץ יימחק לפני שהשלב השני יתבצע. כשמציינים את אמצעי האחסון עם אותו שם בשני השלבים, התוכן של /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`

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

מציינים את 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 בשלב ה-build, מציינים סקריפט מעטפת להפעלה בשלב הזה. אם מציינים את script בשלב build, אי אפשר לציין את args או את entrypoint באותו שלב. במאמר הפעלת סקריפטים של Bash מוסבר איך משתמשים בשדה script.

automapSubstitutions

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

תוצאות

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

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

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

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

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

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 כדי לאחסן את יומני ה-build בקטגוריה שנוצרה על ידי 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: מאפשר למפות שדות מסוימים ביומן ה-build לשדות ב-LogEntry כשיומן ה-build נשלח ל-Logging. לדוגמה, אם יומן ה-build מכיל message, ההודעה מופיעה ב-textPayload או ב-jsonPayload.message ברשומת היומן שנוצרה. שדות של יומן ה-build שלא ניתנים למיפוי מופיעים ברשומה ביומן jsonPayload. מידע נוסף זמין במאמר מיפוי שדות של יומן build לשדות של רשומות ביומן.

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

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

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

‫pubsubTopic: אפשרות לספק שם של נושא Pub/Sub כדי לקבל התראות על סטטוס ה-build. אם לא תציינו שם, 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 יש ארבעה סוגים של מכונות וירטואליות עם מעבדים חזקים להרצת ה-builds: שני סוגי מכונות עם 8 מעבדים ושני סוגי מכונות עם 32 מעבדים. ב-Cloud Build יש גם שני סוגים נוספים של מכונות וירטואליות עם מעבד אחד ושני מעבדים להרצת ה-builds. סוג המכונה שמוגדר כברירת מחדל הוא e2-standard-2 עם 2 מעבדי CPU. בקשה למכונה וירטואלית עם מעבד (CPU) חזק עשויה להאריך את זמן ההפעלה של ה-build. מוסיפים את האפשרות machineType כדי לבקש מכונה וירטואלית עם מעבד (CPU) חזק יותר:

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, אפשר לעיין במאמר האצת תהליכי build.

‫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: משתמשים באפשרות הזו כדי לציין אם רוצים להעביר בסטרימינג את יומני ה-build ל-Cloud Storage. כברירת מחדל, Cloud Build אוסף את יומני ה-build בסיום ה-build. האפשרות הזו מציינת אם אתם רוצים להעביר בסטרימינג את יומני ה-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: באפשרות הזו אתם יכולים לציין אם אתם רוצים לאחסן את יומני ה-build ב-Cloud Logging או ב-Cloud Storage:

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

למידע נוסף על היתרונות והשיקולים של אחסון יומני ה-build, קראו את המאמר אפשרויות אחסון של יומני 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 מוגדר לשלוח את יומני ה-build ל-Cloud Storage.

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

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

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

הגדרת ה-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: מגדירים את הערך של השדה הזה לשם המשאב של המאגר הפרטי שבו רוצים להריץ את ה-build. להוראות להרצת build במאגר פרטי, ראו הרצת גרסאות build במאגר פרטי.

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

workerRelease: בוחרים ערוץ הפצה או גרסה ספציפית.

הגדרת ה-build הבאה מגדירה את השדה workerRelease לערוץ הרגיל:

YAML

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

JSON

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

ובדוגמה הבאה, השדה workerRelease מוגדר לגרסה ספציפית:

YAML

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

JSON

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

`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 כדי לארגן את ה-builds בקבוצות ולסנן אותם. ההגדרה הבאה מגדירה שני תגים בשם 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 KMS בבקשת ה-build. ‫Cloud Build יכול להשתמש בסודות האלה כדי לבצע פעולה במהלך תהליך ה-build, כמו התחברות לחשבון.

Secret Manager

כדי להשתמש בסודות של Secret Manager בקובץ תצורת ה-build, מוסיפים את השדה secretManager לשדה availableSecrets בקובץ תצורת ה-build. השדה secretManager מכיל זוג אחד או יותר של השדות versionName ו-env:

‫versionName: הנתיב לסוד ב-Secret Manager.
‫env: שם מקומי (משתנה סביבה) ששלבי ה-build יכולים להשתמש בו כדי להפנות לסוד.

השדה secretEnv בשלב ה-build מציין באילו משתני סביבה אפשר להשתמש בשלב הזה.

ההגדרה הבאה מראה איך להיכנס ל-Docker באמצעות שם משתמש וסיסמה ל-Docker שמאוחסנים ב-Secret Manager:

YAML

    steps:
    - name: 'gcr.io/cloud-builders/docker'
      entrypoint: 'bash'
      args: ['-c', 'docker login --username=$$USERNAME --password=$$PASSWORD']
      secretEnv: ['USERNAME', 'PASSWORD']
    availableSecrets:
      secretManager:
      - versionName: projects/PROJECT_ID/secrets/DOCKER_PASSWORD_SECRET_NAME/versions/DOCKER_PASSWORD_SECRET_VERSION
        env: 'PASSWORD'
      - versionName: projects/PROJECT_ID/secrets/DOCKER_USERNAME_SECRET_NAME/versions/DOCKER_USERNAME_SECRET_VERSION
        env: 'USERNAME'

JSON

{
  "steps": [
  {
    "name": "gcr.io/cloud-builders/docker",
    "entrypoint": "bash",
    "args": [
      "-c",
      "docker login --username=$$USERNAME --password=$$PASSWORD"
    ],
    "secretEnv": [
      "USERNAME",
      "PASSWORD"
    ]
  }
  ],
  "availableSecrets": {
    "secretManager": [{
      "versionName": "projects/PROJECT_ID/secrets/DOCKER_PASSWORD_SECRET_NAME/versions/DOCKER_PASSWORD_SECRET_VERSION",
      "env": "PASSWORD"
  }, {
    "versionName": "projects/PROJECT_ID/secrets/DOCKER_USERNAME_SECRET_NAME/versions/DOCKER_USERNAME_SECRET_VERSION",
    "env": "USERNAME"
      }]
  }
}

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

Cloud KMS

כדי להשתמש במפתחות של Cloud KMS בקובץ תצורת ה-build, מוסיפים את השדה inline לשדה availableSecrets בקובץ תצורת ה-build. השדה inline מכיל זוג אחד או יותר של kmsKeyName ו-envMap:

‫kmsKeyName: הנתיב למפתח Cloud KMS.
‫envMap: שם מקומי (מיפוי סביבה) ששלבי ה-build יכולים להשתמש בו כדי להפנות לסוד.

השדה secretEnv בשלב ה-build מציין באילו משתני סביבה אפשר להשתמש באותו שלב.

בהגדרה הבאה מוסבר איך להיכנס ל-Docker באמצעות שם משתמש וסיסמה של Docker שמאוחסנים ב-Cloud KMS.

YAML

     steps:
     - name: 'gcr.io/cloud-builders/docker'
       entrypoint: 'bash'
       args: ['-c', 'docker login --username=$$USERNAME --password=$$PASSWORD']
       secretEnv: ['USERNAME', 'PASSWORD']
     - name: 'gcr.io/cloud-builders/docker'
       entrypoint: 'bash'
       args: ['-c', 'docker pull $$USERNAME/IMAGE:TAG']
       secretEnv: ['USERNAME']
     availableSecrets:
       inline:
       - kmsKeyName: projects/PROJECT_ID/locations/global/keyRings/USERNAME_KEYRING_NAME/cryptoKeys/USERNAME_KEY_NAME
         envMap:
           USERNAME: 'ENCRYPTED_USERNAME'
       - kmsKeyName: projects/PROJECT_ID/locations/global/keyRings/PASSWORD_KEYRING_NAME/cryptoKeys/PASSWORD_KEY_NAME
         envMap:
           PASSWORD: 'ENCRYPTED_PASSWORD'

JSON

{
  "steps": [
  {
    "name": "gcr.io/cloud-builders/docker",
    "entrypoint": "bash",
    "args": [
      "-c",
      "docker login --username=$$USERNAME --password=$$PASSWORD"
    ],
    "secretEnv": [
      "USERNAME",
      "PASSWORD"
    ]
  },
  {
    "name": "gcr.io/cloud-builders/docker",
    "entrypoint": "bash",
    "args": [
      "-c",
      "docker pull $$USERNAME/REPOSITORY:TAG"
      ],
      "secretEnv": [
      "USERNAME"
    ]
  }
  ],
  "availableSecrets": {
    "inline": [{
      "kmsKeyName": "projects/PROJECT_ID/locations/global/keyRings/USERNAME_KEYRING_NAME/cryptoKeys/USERNAME_KEY_NAME",
      "envMap": {
        "USERNAME": "ENCRYPTED_USERNAME"
        }
    },
    {
    "kmsKeyName": "projects/PROJECT_ID/locations/global/keyRings/PASSWORD_KEYRING_NAME/cryptoKeys/PASSWORD_KEY_NAME",
    "envMap": {
        "PASSWORD": "ENCRYPTED_PASSWORD"
        }
    }]
  }
}

`secrets`

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

`serviceAccount`

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

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

`images`

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

`objects`

בשדה artifacts, השדה object מציין פריט מידע אחד או יותר שצריך לאחסן ב-Cloud Storage. מידע נוסף זמין במאמר אחסון פריטי מידע שנוצרו בתהליך build ב-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 למאגר quickstart-go-repo ב-Artifact Registry:

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 למאגר https://us-east1-npm.pkg.dev/my-project/my-repo ב-Artifact Registry.

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 למאגר https://us-east1-docker.pkg.dev/my-project/my-repo ב-Artifact Registry.

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 יתחיל. מידע נוסף זמין במאמר ציון פריט מידע גנרי כתלות.

שימוש בקובצי Docker

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

רשת Cloud Build

כש-Cloud Build מריץ כל שלב ב-build, הוא מצרף את מאגר השלב לרשת Docker מקומית בשם cloudbuild. ברשת cloudbuild מתארחים Application Default Credentials (ADC), ששירותי 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 כדי להגדיר גרסאות build ל-Cloud Build.
במאמר התחלת build באופן ידני מוסבר איך מריצים גרסאות build ב-Cloud 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

YAML

JSON

YAML

JSON

substitutions

YAML

JSON

tags

YAML

JSON

availableSecrets

YAML

JSON

YAML

סכימה של קובץ תצורת 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`