[Workers] Add Builds API guide with workflow examples#28229
Conversation
- Document required permissions (Workers Builds Configuration + Workers Scripts Read) - Explain Worker tag vs Worker name (external_script_id) distinction - Add complete workflow: get Worker tag → get trigger UUID → work with builds - Include production vs preview trigger setup with environment variables - Add redeploy script example for refreshing build-time data - Add end-to-end setup example from GitHub repo connection to first build - Add troubleshooting section for common errors
|
/bonk review this PR using the docs agent guidelines |
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
- Remove editorial tone about API docs (line 37) - Simplify troubleshooting section, link to dedicated troubleshoot page - Replace ofetch with built-in fetch in redeploy example
|
Preview URL: https://37cc879b.preview.developers.cloudflare.com Files with changes (up to 15) |
irvinebroque
left a comment
There was a problem hiding this comment.
Let's make sure that references to the REST API link back to the relevant links to Builds API docs at api.cloudflare.com
|
|
||
| ### 1. Create an API token with the correct permissions | ||
|
|
||
| The Builds API requires a user-scoped API token with specific permissions. Create your token at [dash.cloudflare.com/profile/api-tokens](https://dash.cloudflare.com/profile/api-tokens). |
There was a problem hiding this comment.
Does it actually require user scoped? Or is it just that in dash we default to user scoped for ?
| | Permission | Access | Why you need it | | ||
| |------------|--------|-----------------| | ||
| | Workers Builds Configuration | Edit | Trigger builds, update triggers, manage environment variables | | ||
| | Workers Scripts | Read | Retrieve Worker tags (required for all Builds API calls) | |
There was a problem hiding this comment.
@stritt @AdamBouhmad if dash supported deeplinking to API token creation, with specific permissions (or future: roles) as a query param
Then from docs like this we could send someone straight into creating a token with exactly the right permissions / roles
cc @vy-ton
|
|
||
| Here is the typical workflow for interacting with the Builds API: | ||
|
|
||
| ```txt |
There was a problem hiding this comment.
Love having diagram here — maybe worth experimenting with conveying this via Mermaid? Will render nicely
|
|
||
| Call the Workers Scripts API to list all your Workers and find the `tag` for the Worker you want to work with: | ||
|
|
||
| ```bash |
There was a problem hiding this comment.
Is the goal of this guide to show you how you could manually do this via CLI or show you a bit of code that you might write in TypeScript to program around the builds API and have it do things?
| │ | ||
| ▼ | ||
| ┌─────────────────────────────────────────────────────────────────┐ | ||
| │ 2. Get trigger UUID (using the Worker tag) │ |
There was a problem hiding this comment.
At this point I'm not sure we have explained what a trigger is? Does someone need to understand that in order to follow?
- Clarify user-scoped token requirement and link to build token docs - Update Worker tags section title to include external_script_id - Rewrite trigger explanation with production/preview context - Revert to ASCII diagrams for workflow overview - Restructure Examples section with diagrams for each use case - Add multiple sources for obtaining build_uuid - Fix anchor links and API reference URLs
|
/bonk Task: Convert ASCII diagrams to Mermaid in the Builds API reference
Make them even more detailed than the ASCII diagrams based on the text they represent if need be |
Co-authored-by: yomna-shousha <yomna-shousha@users.noreply.github.com>
|
Zero errors. All three ASCII diagrams have been successfully converted to Mermaid format. Here's a summary of the changes: Diagram 1: Workflow overview (line 68)
Diagram 2: Set up Workers Builds from scratch (line 294)
Diagram 3: Redeploy current deployment (line 452)
|
c4de607 to
14e3049
Compare
|
/bonk instead of &{tag&}, &{uuid&}, and &{name&} can you make sure the correct fields are generated if it is incorrect can you remove the text after the endpoint for all diagrams, except ones that are like → note account ID for all mermaid diagrams, can you bold the title instead of the endpoint do you need an endpoint for these: Production trigger and Preview trigger (optional) |
Co-authored-by: yomna-shousha <yomna-shousha@users.noreply.github.com>
|
All changes are complete. Here's a summary of what was changed across all three Mermaid diagrams: Diagram 1: Workflow overview (line 68)
Diagram 2: Set up Workers Builds from scratch (line 294)
Diagram 3: Redeploy current deployment (line 452)
|
|
Hey there, we've marked this pull request as stale because there's no recent activity on it. This label is helps us identify PRs that might need updates (or to be closed out by our team if no longer relevant). |
| ```bash | ||
| curl -s "https://api.cloudflare.com/client/v4/accounts/{account_id}/builds/workers/{worker_tag}/triggers" \ | ||
| --header "Authorization: Bearer <API_TOKEN>" \ | ||
| | jq '.result[] | {trigger_uuid, trigger_name, branch_includes, branch_excludes}' |
There was a problem hiding this comment.
Are we comfortable assuming jq is installed for everyone? It isn't a default package on any common OSes. Even just a link out to where you can download it would be helpful for people that are unfamiliar.
|
|
||
| Save the `trigger_uuid` for the trigger you want to work with. Remember, you will have at most two triggers: one for your production branch (for example, `main`) that deploys to your live Worker, and optionally one for all other branches that creates preview deployments. | ||
|
|
||
| ## Step 3: Work with builds |
There was a problem hiding this comment.
It's kinda weird to talk about using a trigger before you show how to create one. I know that comes later on in the doc, but I'd consider flipping the order.
|
|
||
| The response includes `build_uuid` for each build, which you need for getting logs or canceling builds. | ||
|
|
||
| ### Get build logs |
There was a problem hiding this comment.
Do we have a WebSocket streaming endpoint we want to document?
| --data '{ | ||
| "branch": "{branch}", | ||
| "commit_hash": "{commit_hash}" | ||
| }' |
There was a problem hiding this comment.
You said earlier that you can specify branch "or" commit_hash. Is it "and/or"?
Addressed bonk's review
This PR adds a new guide for using the Workers Builds API.
The guide covers: