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
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.
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.