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.
New trigger feature (like skip ci or tag based triggering) are only available if you use the new hooks.bitrise.io webhook URL!
Initially we had a non open source bitrise.io/hooks endpoint for webhooks, but every new project registered should now get the new hooks.bitrise.io webhook URL automatically.
If your webhook would still be a bitrise.io/hooks URL, please replace it with the new hooks.bitrise.io/ URL - you can find this on the Code tab of your app!
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.
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!
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.
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 Requests for it @rramgarhia
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.
For now we don’t plan to support this out of the box (feel free to create a Feature Requests 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 Bitrise.io API v0.1 (Work In Progress) and it’s definitely on the “coming soon” list