|
| 1 | +This playbook provides instructions for Carvel/Kubernetes tile teams to onboard their tiles onto the Golden Path to publish workflow. |
| 2 | + |
| 3 | +For Carvel-based tiles, intermediary BOSH releases are generated automatically from imgpkg bundles (via ezbake) and do not need to be managed directly by your team. GPP handles BOSH release ingest and compilation behind the scenes. Your team only needs to manage final tile releases. |
| 4 | + |
| 5 | +The result of this work will give you a re-bakable tile in [Artifactory](https://usw1.packages.broadcom.com/ui/repos/tree/General/tas-ecosystem-generic-prod-local/tile-releases) with compiled BOSH releases that is scanned by BlackDuck. For TVS integration please notify the Slingshots team when you're ready for it along with a link to your config please. |
| 6 | + |
| 7 | +You may also optionally configure your Tile to generate RMT releases, and Open Source License Disclosure files from Blackduck. |
| 8 | + |
| 9 | +## Pre-requisites for onboarding |
| 10 | + |
| 11 | +### Your tile is built with Kiln |
| 12 | + |
| 13 | +The Golden Path does not currently support tiles built with [tile-generator](https://github.com/cf-platform-eng/tile-generator). |
| 14 | + |
| 15 | +Please consider using [kiln](https://github.com/pivotal-cf/kiln/blob/main/TILE_AUTHOR_GUIDE.md). Carvel tile workflows use the `kiln carvel` subcommand group (`bake`, `upload`, `publish`, `rebake`). |
| 16 | + |
| 17 | +### Github repo access: tiles |
| 18 | + |
| 19 | +Please provide write access to your private tile repositories to our bot account. Because BOSH releases are generated from the tile source (imgpkg bundles), separate BOSH release repositories are not required. |
| 20 | + |
| 21 | +- For github enterprise (github.gwd.broadcom.com): [tanzu-tas-ecosystem](https://github.gwd.broadcom.net/tanzu-tas-ecosystem) |
| 22 | +- for github.com: [tas-ecosystem-bot](https://github.com/tas-ecosystem-bot) |
| 23 | + |
| 24 | +### TNZ team membership |
| 25 | + |
| 26 | +To create PRs against our configuration repo you need to be a member of the [`all`](https://github.gwd.broadcom.net/orgs/TNZ/teams/all) team in the [TNZ org](https://github.gwd.broadcom.net/orgs/TNZ). |
| 27 | + |
| 28 | +### Broadcom artifactory access |
| 29 | + |
| 30 | +Authentication is required for accessing repos and artifacts on the Broadcom Jfrog Artifactory service. To get access for your team to our artifact repos containing: bosh-releases, compiled-releases, tile-releases and tile-candidates, create a [1.Support Ticket](https://broadcomitsm.wolkenservicedesk.com/wolken-support/item_details?itemId=2422). |
| 31 | +Specify: |
| 32 | + |
| 33 | +- Artifactory Server Name / URL: `https://usw1.packages.broadcom.com/ui` |
| 34 | +- Sample Business Justification: |
| 35 | + |
| 36 | + ```text |
| 37 | + Need read access to tas-ecosystem-* artifactory projects on https://usw1.packages.broadcom.com |
| 38 | +
|
| 39 | + For the following teammates / service accounts: |
| 40 | + - memberX |
| 41 | + - memberY |
| 42 | + - memberZ |
| 43 | + - bot / service account |
| 44 | + ``` |
| 45 | + |
| 46 | +#### Credentials |
| 47 | + |
| 48 | +Since artifactory is authenticated with Okta SSO, password authentication to the service it not allowed. Artifactory have `api_keys` and `identity_tokens` that are used as passwords. |
| 49 | + |
| 50 | +Once access is granted and you are able to login to the artifactory ui via SSO, an `api_key` or `identity token` needs to be created for use with Kiln |
| 51 | + |
| 52 | +1. Upper right click dropdown of: `Welcome, your_username` |
| 53 | +2. Click `Edit Profile` |
| 54 | +3. Create an `api_key` or `identity_token` here and use it as the password for `kiln` commands or the artifactory cli. |
| 55 | + |
| 56 | +#### Network access |
| 57 | + |
| 58 | +The `usw1.packages.broadcom.com` artifactory is also only available on the Broadcom network. If accessing remotely, full tunnel VPN is required. |
| 59 | + |
| 60 | +If you CI is on the VMware / Broadcom Network and is blocked from accessing the artifactory, reach out to Google Chat Space: [#VMW-harbor-jfrog-migration](https://chat.google.com/room/AAAAcWIWWOA?cls=7) |
| 61 | + |
| 62 | +## Golden Path Configuration |
| 63 | + |
| 64 | +Configuration for the TAS Golden Path is stored in this repo and used as inputs to generate concourse pipelines. |
| 65 | + |
| 66 | +For Carvel-based tiles, the onboarding is simpler than for traditional BOSH tiles because GPP manages BOSH release ingest and compilation behind the scenes. You do not need to add BOSH release config files to the `bosh/` folder. The existing [bosh-ingest](https://tpe-concourse-rock.acc.broadcom.net/teams/tas-ecosystem/pipelines/bosh-releases?group=ingest-releases) and [bosh-compile](https://tpe-concourse-rock.acc.broadcom.net/teams/tas-ecosystem/pipelines/bosh-releases?group=compile-releases) pipelines are available for inspection if needed but do not require configuration from your team. |
| 67 | + |
| 68 | +Overall the following steps to complete are: |
| 69 | + |
| 70 | +- Updating the `Kilnfile` in the git repository to use artifactory as a source for generated BOSH releases. |
| 71 | +- (optional) Creating a branch in the git repository of your tile for a pipeline to push Kilnfile.lock updates for your review. |
| 72 | +- Creating config files for your tile(s) in `tiles/` folder to generate pipeline that will: |
| 73 | + - Bake tile candidates with `kiln carvel bake`. Dev builds of tiles on your main / feature branch |
| 74 | + - [`kiln carvel rebake`](https://github.com/pivotal-cf/kiln) for versioned release tiles |
| 75 | + - Associate the BOSH releases consumed by the tile to the Blackduck tile project |
| 76 | + - (optional) Automatically creates RMT releases that are included in the next-available TPM managed Release Train to assist with publishing |
| 77 | + - If RMT is enabled, then your RMT release is eligible for automatic Open Source License Notice inclusion. Please see [creating open source license disclosures](./creating_open_source_license_disclosures.md). |
| 78 | + - (optional) TVS integration (notify the #tas-slingshots team with your tile config requesting this when ready) |
| 79 | + |
| 80 | +### Tile repository updates |
| 81 | + |
| 82 | +Set up your tile repository so that `kiln carvel` commands can fetch generated BOSH releases from Artifactory. |
| 83 | + |
| 84 | +1. In the main / feature branch, update the `Kilnfile` to include artifactory as the remote source for BOSH releases. |
| 85 | + |
| 86 | + ```yaml |
| 87 | + release_sources: |
| 88 | + - type: artifactory |
| 89 | + id: artifactory_bosh_releases |
| 90 | + artifactory_host: $(variable "artifactory_host") |
| 91 | + repo: $(variable "artifactory_repo") |
| 92 | + username: $(variable "artifactory_username") |
| 93 | + password: $(variable "artifactory_password") # api_key or identity token |
| 94 | + publishable: true # if this repo contains releases that are suitable to ship to customers |
| 95 | + path_template: bosh-releases/{{.Name}}/{{.Name}}-{{.Version}}.tgz |
| 96 | + ``` |
| 97 | +
|
| 98 | +2. Use `kiln carvel upload` to generate the BOSH release from your imgpkg bundle, upload it to Artifactory, and update the `Kilnfile.lock` with the remote location and checksum. |
| 99 | + |
| 100 | + Example `kiln carvel upload` command: |
| 101 | + |
| 102 | + ```bash |
| 103 | + $ kiln carvel upload \ |
| 104 | + --artifactory-host https://usw1.packages.broadcom.com \ |
| 105 | + --artifactory-repo tas-ecosystem-generic-prod-local \ |
| 106 | + --artifactory-username <your_user_or_bot_account> \ |
| 107 | + --artifactory-password <api_key-or-identity_token> \ |
| 108 | + --output-file my-tile-1.0.0-dev.pivotal |
| 109 | + ``` |
| 110 | + |
| 111 | + This uploads the generated BOSH release and writes a `Kilnfile.lock` referencing the remote artifact. Commit the updated `Kilnfile.lock` to your repository. |
| 112 | + |
| 113 | +3. (Optional) Create a new update branch from the main / feature branch in your tile repository (eg: `autobump`). Our CI will force push commits to this branch. |
| 114 | + While this provides an auto update functionality, you are welcome to continue using your existing auto update tools (eg: dependabot). |
| 115 | + You can also specify your feature branch if you want our CI to push the `Kilnfile.lock` updates directly to your feature branch. |
| 116 | + If `branch` and `update_branch` are same, force push functionality is disabled. Ensure the branch specified in `update_branch` has [push access to our bot account](#github-repo-access-tiles). |
| 117 | + |
| 118 | +### Tile config onboard |
| 119 | + |
| 120 | +1. Clone [this](https://github.gwd.broadcom.net/TNZ/tas-ecosystem-configuration) git repository if you have not already and create a branch locally for your changes. You should have write access to the repo and not need to create a fork to create a PR. If not, please review [this pre-requisite](#tnz-team-membership) |
| 121 | + |
| 122 | +2. Create a new file for each of your tiles under the [tiles](https://github.gwd.broadcom.net/TNZ/tas-ecosystem-configuration/tree/main/tiles) directory. Please note that `artifact_name` is especially significant because it determines the file name prefix in `artifactory`, project names prefixes in `blackduck`, and is the prefix used by the published release file in RMT / Broadcom Portal (when enabled). |
| 123 | + Hello Tile - `hello-tile.yml` |
| 124 | + |
| 125 | + ```yaml |
| 126 | + #@data/values |
| 127 | + --- |
| 128 | + repo: https://github.gwd.broadcom.net/TNZ/hello-tile.git |
| 129 | + branch: main |
| 130 | + update_branch: auto-bump |
| 131 | + subpath: . |
| 132 | + artifact_name: crhntr-hello #! this is the prefix for the built tiles and must be consistent with blackduck too |
| 133 | + prerelease_format: build_increment_sha #! "sha" or "build_increment_sha" for versioning tile candidate builds. we recommend build_increment_sha |
| 134 | + team_members: |
| 135 | + - a@vmware.com |
| 136 | + - b@vmware.com |
| 137 | + team_google_chat_group: some-group #! required - google space / chat group for your team |
| 138 | + team_slack_channel: some-channel #! If your team has slack channel |
| 139 | + ``` |
| 140 | + |
| 141 | + Scheduler Tile - `p-scheduler.yml` (auto update directly on feature branch) |
| 142 | + |
| 143 | + ```yaml |
| 144 | + #@data/values |
| 145 | + --- |
| 146 | + repo: https://github.com/pivotal-cf/p-scheduler.git |
| 147 | + branch: master |
| 148 | + update_branch: master |
| 149 | + subpath: . |
| 150 | + artifact_name: p-scheduler #! this is the prefix for the built tiles and must be consistent with blackduck too |
| 151 | + prerelease_format: build_increment_sha #! "sha" or "build_increment_sha" for versioning tile candidate builds |
| 152 | + team_members: |
| 153 | + - a@vmware.com |
| 154 | + - b@vmware.com |
| 155 | + team_google_chat_group: some-group #! required - google space / chat group for your team |
| 156 | + team_slack_channel: some-channel #! If your team has slack channel |
| 157 | + ``` |
| 158 | + |
| 159 | +3. (optional) Add fields for automatic RMT _**draft**_-release creation |
| 160 | + |
| 161 | + >**Warning:** You will need to add upgrade specifiers (else Upgrade Planner will break!) and double check your release is ready to be set to GA. It defaults to a draft. |
| 162 | + |
| 163 | + Release tiles can be used as the basis for automatic `RMT` draft release creation. As a draft this means further steps are required prior to publishing. These include manually setting your upgrade specifiers, double checking the version, GA/EOGs dates, and release type, etc we inferred for you or read from your tile configuration's `rmt` entry. |
| 164 | + |
| 165 | + See [tile rmt release](https://github.gwd.broadcom.net/TNZ/tas-ecosystem-configuration/tree/main/docs/tile_rmt_release.md) for details. |
| 166 | + |
| 167 | +4. (optional) Add a field to enable automatic Black Duck tile project associations. In order to begin updating your Black Duck tile project: |
| 168 | + >**Prerequisites:** |
| 169 | + > Follow the [BlackDuck Onboarding section](./creating_open_source_license_disclosures.md#blackduck-onboarding) for |
| 170 | + > your tile. BOSH release projects are managed by GPP for Carvel-based tiles. |
| 171 | + |
| 172 | + 1) Confirm your project exists @ https://broadcom-vmw.app.blackduck.com/ with the format `TNZ-CF-<artifact_name>-tile`, as `<artifact_name>` is found in your tile config. |
| 173 | + 2) If not, submit a ticket to request it ([BlackDuck Onboarding section](./creating_open_source_license_disclosures.md#blackduck-onboarding)) or rename it yourself. |
| 174 | + > **Note:** Scanning is enabled by default. However, you may disable it by adding the following to your `./tiles/<tile>.yml` config: |
| 175 | + ```yaml |
| 176 | + blackduck: |
| 177 | + enabled: false |
| 178 | + ``` |
| 179 | + |
| 180 | +5. Create a PR to [this](https://github.gwd.broadcom.net/TNZ/tas-ecosystem-configuration) repository to add the newly created files that contain the tile information. |
| 181 | +An extensive PR Check job will verify your change and add a comment if anything needs to be addressed. When the job passes you can merge the PR. |
| 182 | +On merge, the respective golden path jobs will be created / updated for your tile. Please reach out to [#tas-slingshots on Google Chat](https://chat.google.com/room/AAAAZuDvKe0?cls=7) with any questions or issues getting your PR merged. |
| 183 | + |
| 184 | +## Updating CI for your tile and automatic RMT _draft_ releases |
| 185 | + |
| 186 | +### Use `kiln carvel publish --final` |
| 187 | + |
| 188 | +If you are using CI to create new versions of tiles, the following updates can be made to take advantage of reproducible builds via `kiln carvel rebake`. |
| 189 | + |
| 190 | +Update your CI to output final tile builds using `kiln carvel publish --final`. When passing the **_--final_** flag, Kiln creates a bake record file under the **_bake_records_** folder. As part of the final tile build CI job, the bake records file needs to be committed and pushed to the tile repository. |
| 191 | + |
| 192 | +Golden Path to publish will then use this bake record to trigger `kiln carvel rebake`, producing a final tile from our [CI](https://runway-ci-srp.eng.vmware.com/teams/tas-ecosystem/) and upload it to [artifactory](https://build-artifactory.eng.vmware.com/ui/repos/tree/General/tas-ecosystem-generic-local/) repo under the sub-path: tile-releases. |
| 193 | + |
| 194 | +In the case of a pre-release version the build will not result in a publish. This is useful to verify OSL triage status and test your candidate build. For example, you may create a |
| 195 | +bake record with version `2.4.41-dev.0`, rerun the OSL generation multiple times, then finally create a `2.41.1` to trigger the full publish. |
| 196 | + |
| 197 | + Example `kiln carvel publish --final` command: |
| 198 | + |
| 199 | + ```bash |
| 200 | + $ kiln carvel publish --final --version 2.1.41 \ |
| 201 | + --output-file my-tile-2.1.41.pivotal \ |
| 202 | + --source-directory . |
| 203 | + ``` |
| 204 | + |
| 205 | + _Example:_ Bake record that should be committed to the tile repo that is created by `kiln carvel publish --final` as file: `bake_records/2.1.41.json`: |
| 206 | + |
| 207 | + ```json |
| 208 | + { |
| 209 | + "source_revision": "1b19d8cb80e6cfdddd7be1c7a26c8210cbd4e4c5", |
| 210 | + "version": "2.1.41", |
| 211 | + "kiln_version": "0.90.0", |
| 212 | + "file_checksum": "7622143c54dc53087a6c2401f5030170515e14f466857564a980092d4c87a094", |
| 213 | + "tile_directory": "." |
| 214 | + } |
| 215 | + ``` |
| 216 | + |
| 217 | +When executing `kiln carvel publish --final`, use the values for artifactory variables in your Kilnfile: |
| 218 | + |
| 219 | +- artifactory_host: `https://usw1.packages.broadcom.com` |
| 220 | +- artifactory_repo: `tas-ecosystem-generic-prod-local` |
| 221 | +- artifactory_username: **_your account or service account for broadcom artifactory_** |
| 222 | +- artifactory_password: **_respective api_key or identity token_** |
| 223 | + |
| 224 | +**_NOTE: https://usw1.packages.broadcom.com is accessible via Broadcom VPN with full tunnel gateway and TPE concourse workers_** |
| 225 | + |
| 226 | +**_Commit the new bake record to the git repository of the tile_** |
| 227 | + |
| 228 | +**_Warning: Your bake_records directory must only contain bake records_** |
| 229 | + |
| 230 | +GPP will then automatically run `kiln carvel rebake` against the bake record to produce the final `.pivotal` file, validate the checksum, and upload it to Artifactory and optionally RMT. |
| 231 | + |
| 232 | +Please refer to [Tile RMT Release](Publish-Tiles-to-RMT) to configure publishing your tile to RMT via Golden Path to Publish. |
0 commit comments