Duplicated build number when triggered via webhook

Bitrise Build Issue Report template

Description of the issue

We’ve setup Slack slash command which allows to trigger builds on bitrise.io. It works via intermediate web-service, and it can trigger up to 3 builds simultaneously (3 different environments: dev, stage, prod). We use POST to https://app.bitrise.io/app/.../build/start.json with required parameters to trigger builds. Last time, we tried to trigger 3 builds at once, and everything was good, except build numbers. See screenshot here: https://take.ms/vcPiG

Hi @shpuntov!

That’s interesting, thanks for reporting! Do those two builds still exist with the identical build number or was this only displayed like this on the dashboard?

Hey @bitce — yes, those two builds still exist and have the same build number, which is displayed on the dashboard, and on individual build pages. By the way, after I reported this issue, I’ve queued my builds again with the same way, and I got “triplicated” build number 181: https://take.ms/CY9su

Interesting thing: the next build number will be 184, i.e. we skip 182 and 183 anyway. The same as we skipped 179 in the previous case.

What solution are you using to make this happen?

Could you try the API instead?

We created Slack slash command which helps us to queue builds right from Slack. We usually build our IOS app for 3 environments at once: dev, stage and prod. When we enter this slash command in a Slack channel, it sends POST with parameters to our intermediate web service, which just parses those parameters, and sends requests to https://app.bitrise.io/app/.../build/start.json for each environment, in the loop actually. So these 3 requests go simultaneously, we don’t wait for response from a request to send a next one.

As we can see, bitrise reserves 3 build numbers for 3 triggered builds, but for some reasons it assign wrong build numbers for some builds. I believe it should be some lock on database or backend level, so that every build has it’s own unique build number.

We could try the API instead, but this will take some time to change our web service, and I’m not sure when we can allocate enough time for that. Also it makes more sense for me to use POST to https://app.bitrise.io, because it doesn’t require authentication, and looks like more lighweight solution which work perfect for our case.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.