how to detect if a pipeline is a scheduled run
Asked by J_ Stolp:

I'm having a hardtime trying to figure out how to check if a pipeline run is scheduled.  
The documentation says:  

|-------------------------------|------------------------------------------------------------------------------------------------------------------------------|
| BITBUCKET_STEP_TRIGGERER_UUID | The person who kicked off the build ( by doing a push, merge etc), and for scheduled builds, the uuid of the pipelines user. |

We have E2E tests that you can run manually, and they run nightly off a schedule.  
if i use my personal UUID in a check, it works (i.e. i hardcode it into the check, and that never changes. but it seems the UUID of the pipelines user is not fixed.  

How to figure out the *uuid of the pipelines user.* i.e.  
if \[ "$BITBUCKET_STEP_TRIGGERER_UUID" == "what-uuid-here" \]; then  
...  
fi  

or is there some other way to check if this is a scheduled launch and/or a manual run?


Answers:
author: Ben
body: G'day J!

Welcome to the Bitbucket Cloud community!

The uuid of a Pipelines user should be fixed as this UUID is tied to the user account of the person who has executed the build.

May I know if the scheduled builds you have mentioned show that they have been executed by a specific user or if they are some system/bot user? You can check this by hovering over the user avatar in the pipelines build log (bottom right of the left-hand side of the build log panel)

Cheers!

- Ben (Bitbucket Cloud Support)

comments: author: J_ Stolp
body: So it worked when i tested it via my own UUID (i've launched the pipeline) then it'll post the notification and pass the If check  

if \[ "$BITBUCKET_STEP_TRIGGERER_UUID" == "my-uuid-here" \]; then  
# this works when my user account launches the build.  
fi  

But in this case it's scheduled:  

![Screenshot 2024-04-09 at 08.15.23.png](https://community.atlassian.com/t5/image/serverpage/image-id/317142iEF194ED08FB834EA/image-size/large?v=v2&px=999 "Screenshot 2024-04-09 at 08.15.23.png")  
Where can i get the UUID of the Scheduled user?  

P.s. I've worked around it now by matching the time of the build with a check the build runs at 00:00z and since its running very night on time i've modified the check to:  

# Only trigger if it's a scheduled run (i.e. Nightly) between 00:00 and 03:00 UTC  
if \[ "$(date +%H)" -lt 3 \]; then  
fi  
...  

And now it triggers.


author: Ben
body: Hi [@J_ Stolp](/t5/user/viewprofilepage/user-id/5469952)

I'm glad to hear you have a workaround in place. Do you have any luck getting some further information from our Pipelines API?

We have a Pipelines endpoint that lists all builds (trigger type should say scheduled) as well as an endpoint specifically for all pipelines schedules specifically:

* [List Pipelines](https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pipelines/#api-repositories-workspace-repo-slug-pipelines-get)
* [List Schedules](https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pipelines/#api-repositories-workspace-repo-slug-pipelines-config-schedules-get)
* [List Execution UUID of a Schedule](https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pipelines/#api-repositories-workspace-repo-slug-pipelines-config-schedules-schedule-uuid-executions-get)

Hope this helps.

Cheers!

- Ben (Bitbucket Cloud Support)


author: Che Fisher
body: Hello there [@Ben](/t5/user/viewprofilepage/user-id/4537226) and [@J_ Stolp](/t5/user/viewprofilepage/user-id/5469952), don't mean to hijack a post but landed hear searching this functionality - I want to detect whether a pipeline has been manually triggered or not.

The wording of the docs is a bit unclear, for example \`BITBUCKET_PR_ID\` has a description of "...Only available on a pull request triggered build" - but what does that mean exactly?   

Will this value be empty if the pipeline is triggered manually (by choosing Run Pipeline \> $branchName \> $pull-requestPipeline) even if there is in fact an open pull request? Or will it only be empty if there is no open PR with a commit hash as its tip that is equal to the branch head?

That may solve it for pipeline triggered builds, but how can I tell if a branch trigger pipeline has been manually triggered? The step schema includes a \`trigger: manual\` property, wondering if there's a reliable way to do this for both branch and pull-request triggered pipelines.


author: J_ Stolp
body: [@Che Fisher](/t5/user/viewprofilepage/user-id/5419517)

I've done a quick test the easiest way to check is to open a PR to a branch, and then trigger a manual build on it (custom: pipeline).

i see in the step Build setup Build setup (log output)

<br />

Default variables:  
...

BITBUCKET_PROJECT_UUID  
BITBUCKET_PR_DESTINATION_BRANCH  
BITBUCKET_PR_DESTINATION_COMMIT  
BITBUCKET_PR_ID  
...

i.e. triggerType=Push

Then you know the value is SET (this is the case for triggers on "PUSH" -\>

but "MANUAL"

i.e. triggerType=Manual

doesn't have these variables set.

<br />

Even triggering the pull-requests manually flow it doesn't seem to be set.  
Thus if BITBUCKET_PR_ID is not set / i.e. empty, it's a manual run


author: Che Fisher
body: This was helpful thank you [@J_ Stolp](/t5/user/viewprofilepage/user-id/5469952) - set me on the right path. For future eyeballs, if you're looking for a way to reliably check if the pipeline trigger is a PR or branch trigger (regardless of whether or not it is run manually) we are using this rather duckish solution:

```
 # if the PR ID is set or the deployment env undefined it's a PR job 
 is_test_job () {
     if [[ $BITBUCKET_PR_ID ]] || [[ -z $BITBUCKET_DEPLOYMENT_ENVIRONMENT ]]; then return 0; else return 1; fi
 }
```

<br />

We needed to know whether or not a job was a PR triggered job or a branch triggered job even when triggering the PR or branch job manually.  

It gets tricky given that something can be a PR "job" (i.e. defined as a PR trigger) and still have the PR ID be empty.  

In our case we only ever deploy on branch merge events, so we can infer that if the deployment environment value isn't set it's a PR job - but it's a duck-typing workaround for sure.


Tags: bitbucket-cloud

cloud