How to use [skip ci]

I have followed this guide to skip CI for a specific pull request or commit push but unfortunately it doesn’t seem to work.

I tried to specified to a Pull Request title but not success.
More often, I push changes to a Pull Request by specifying in the message [skip ci] but I can see Bitrise is executing it anyway.

What am I doing wrong?

Hi @iamfabiomilano ,

Can you please check your webhook URL on GitHub/Bitbucket?

The old hook URL ( does not support the features we added recently, only the new ones do.

From the related blog post (

Update your webhook URL if it’s the old one!

New trigger feature (like skip ci or tag based triggering) are only available if you use the new webhook URL!

Initially we had a non open source endpoint for webhooks, but every new project registered should now get the new webhook URL automatically.

If your webhook would still be a URL, please replace it with the new URL - you can find this on the Code tab of your app!

1 Like

Unfortunately I have to bring this up again.

After I have applied the changes you mentioned in the comment the [skip ci] keyword in the last commit message made everything work as expected. Although, without changing any configuration since it was working, I’m currently having the issue coming up again: even if I specify [skip ci] in my commit message, bitrise kicks off.

How can I best debug this?

Hi @iamfabiomilano - is that a pull request build? PR builds behave differently, there you have to add the skip ci keywords to the title or description:

This means that, if you want to skip a pull request, you have to include the Skip CI pattern in the Pull Request’s title or description, and not in the commit’s message!

1 Like

Is this a new behaviour? I’m quite sure I was able to use [skip ci] even on Pull Request build.

Anyway thank you for closing the missing gap.

Not new, in case of PR builds this was always the case, due to technical limitations mentioned in the docs (

Hi, along the same line I was wondering if Bitrise should automatically set Github check status to pass when [skip ci] is used. We’re unable to merge the PR because the check status are stuck on pending.

1 Like

I personally think that [skip ci] should only be used when there’s absolutely no other solution (e.g. a commit generated by a build, where [skip ci] is required to prevent an infinite build cycle). A PR should never be merged without a test.

That said we’re of course always open to consider a new feature, just create a #feature-request for it @rramgarhia :wink:

Thanks for replying! I totally agree with you on running the tests on every PR, though some PRs may not require running tests, for instance a PR having only documentation update. I think there should be a rule on Github for these specific PRs.


I definitely agree, would be fantastic! :slight_smile:

For now we don’t plan to support this out of the box (feel free to create a #feature-request for that!), but soon you’ll be able to abort a build through our API (in beta right now) with a non “error” status, which could be used to do something like what you described, e.g. with a Script step as the first step in the workflow, where you can decide whether the build should proceed and if not what “status” should be used for the build cancel. You can find some discussion here API v0.1 (Work In Progress) and it’s definitely on the “coming soon” list :wink: