Pipelines

Trigger a pipeline

Tap the trigger button on the Pipelines tab. The form has four parts.

1. Repository. Pick one of your watched repositories.
2. Target. Choose a branch, a tag, or a commit.
3. Pipeline. The app reads bitbucket-pipelines.yml at that target and lists its custom pipelines. "Default for branch" (or tag, or commit) lets Bitbucket choose the pipeline for that target from the same file. If the file cannot be read, you can still run the default pipeline or type a custom pipeline name.
4. Variables. If the custom pipeline declares variables in its variables: block, they appear as fields with their defaults, and as a choice list where the file names allowed values. Add any other variable with Add Variable.

The summary shows everything that will be sent before you confirm.

Secured variables

Turn on Secured for a variable that holds a secret. Bitbucket masks secured values in logs and never returns them through its API. Source Pocket masks them on screen, does not save them, and does not log them. A saved preset keeps the variable name but not a secured value, so the app asks for it each time you use the preset.

Production pipelines

Bitbucket has no flag for production pipelines, so the app guesses from the name: a custom pipeline whose name contains the word prod, production, prd, live, or release, or a ref that starts with release/ or prod, is marked as production. You can switch Production deployment on or off yourself. A production trigger asks for Face ID, Touch ID, or your passcode before it is sent.

Run detail

A run shows its status, branch or tag, commit, pipeline name, who or what started it, duration, and time spent queued, followed by its steps, each with its own status and duration. Parallel steps are grouped. Status is always shown as a word and an icon, not by color alone.

The run refreshes every 20 seconds while it is active. That interval keeps the app inside Bitbucket's hourly request limit; see the limits page.

The Actions menu has Stop, Re-run, Track This Run (a Live Activity on the Lock Screen and in the Dynamic Island), Copy Link, Share, and Open in Browser.

Logs

Tap a step to open its log. Colors from the build output are kept. Search with Find in log and step through matches, turn Follow Tail and Wrap Lines on or off, copy a line, or share 50 lines from any point.

While a step runs, the log fetches only the bytes it has not seen yet, every 8 seconds, slowing to every 30 seconds while nothing new arrives. It stops when the step ends.

Jump to First Error

When a Bitbucket step fails, the log prints lines such as "Skipping cache upload for failed step". The app finds the last command before that line, which is the one that failed, and jumps to the first error-looking line after it. If the log has no such marker, it jumps to the first line that matches a common failure pattern.

Re-run

Bitbucket's API has no re-run. Re-running in Source Pocket starts a new run, with a new build number, on the same ref.

• Default and branch pipelines: Re-run… asks you to confirm, then starts the default pipeline for that ref again.
• Custom pipelines: Re-run with Trigger Form… opens the trigger form with the ref and pipeline name filled in. Variables are not copied, because Bitbucket never returns secured values and a re-run that silently dropped them could deploy with the wrong settings. Enter them again, or start from a preset.

Bitbucket's "Rerun failed steps" button on bitbucket.org has no API, so the app cannot offer it.

Stop

Stop… asks you to confirm, and stops every step that has not finished. A production pipeline asks for Face ID, Touch ID, or your passcode first.

Stop is hidden on a run that is only waiting on a manual step. Every automatic step in that run has already finished, so nothing is running. Bitbucket accepts a stop request for that run, reports success, and leaves the run as it was.

Manual steps

A step marked trigger: manual pauses the run until someone starts it. Bitbucket's API cannot start a manual step, so Source Pocket hands you over to bitbucket.org for that one tap.

1. The run shows Waiting for you to run and the name of the step, and explains that nothing is running.
2. Tap Continue in Bitbucket. The run opens on bitbucket.org inside the app.
3. Tap Run on the step in Bitbucket's page, then tap Done.
4. The app refreshes the run straight away, and keeps refreshing as the step runs.

The in-app browser

bitbucket.org opens in Safari's in-app browser (SFSafariViewController), not in a web view the app controls. Safari runs the page in its own process, so Source Pocket cannot read the page, its cookies, or anything you type, and AutoFill and passkeys work as they do in Safari.

Sign in to Bitbucket there once. The in-app browser keeps its own website data for Source Pocket, so later visits stay signed in until Atlassian ends the session. That session is separate from Safari's and from the API token the app uses.

The first-time notice

The first time you tap Continue in Bitbucket, a notice titled Continue on bitbucket.org explains why the step has to be started there. Choose OK to continue, or Don't Show This Again to continue and skip the notice from then on.

To bring it back, open More, find the Bitbucket section, and turn on Explain before opening bitbucket.org.