Just and update and a question; we did discuss this a couple of times with the team and right now weâre thinking about something like this (question is what you think about it):
We would provide an alternative webhook server as a premium feature, most likely for an additional fix cost per app, which would include the required features to fetch the file change data from GitHub/Bitbucket/âŚ
With this, instead of the previously mentioned flow:
We could simply:
GitHub/Bitbucket/... -> PREMIUM-WEBHOOKS.bitrise.io (-> call back to GitHub/Bitbucket/.. to fetch additional infos) -> bitrise.io (start build)
From an architectural point of view this seems to be the right solution, the question is whether youâd be OK with paying ~$10/mo/bitrise.io app for this feature.
The interface for defining the file filters could remain the Trigger Map, no additional settings would be required, the Trigger Map syntax would be extended.
And overall pretty much every interface/troubleshooting feature could remain the same (e.g. the ones described at Redirecting⌠- Bitrise Docs ), so the tooling could remain unified and you wonât have to learn about additional tools for e.g. debugging/troubleshooting.
Iâd prefer this be part of the âelite tier.â The problem with billing âper appâ is it isnât per app, itâs per CI job. Mono repos mean we have an ever growing amount of jobs. Having unpredictable billing as we use the service more doesnât make sense. Itâs similar to how GitHub use to charge per repo and now they charge per user. If the billing model limits use of the service then thatâs a bit strange.
Buddybuild has the right model I think. Features are based on different tiers of concurrency.
@bootstraponline an update for the âabort API with statusâ - the API should be ready soon, so that youâll be able to abort builds with success (1) and error (2) codes in addition to the default âabortedâ (3) code, using the API.
Unfortunately the UI will also have to be tweaked for this a bit, and that most likely wonât be released this week, but if youâre interested just let me know and we can do a beta test. Technically it will work (on an API level) but the web UI will show those builds the same way as any other success/error build, e.g. wonât show the abort reason text; those will come a bit later.
Thanks to bitrise, we now have a solution for building only changed code. In the future, the shell script will go away in favor of first class mono repo support.
Just one note, this script uses the undocumented new abort endpoint params, but should be safe to use / we donât expect to change that in the foreseeable future, and should be documented on the devcenter soon
So, I have a mono repo with the structure already described:
app1/
app2/
As far as I understand the script attached by @bootstraponline could be used if you have multi bitrise projects for the same repo. Is there any way to have one bitrise project with multiple workflows or even better to skip a certain step of the workflow if nothing changed?
@SoHotSoup sure it is possible, via custom scripts. In general the suggestion is that if you have 2 app projects in the repo then add it as 2 separate apps on bitrise.io
@viktorbenei Thank you! I have opted for more bitrise apps already⌠I have achieved build skipping by using and modifying script provided by @bootstraponline.
Weâd love this feature as well.
Instead of calling apiâs wouldnât it be easier to check the git history itself in a step, and then supporting a skipped build status? Or am I missing something?
Instead of calling apiâs wouldnât it be easier to check the git history itself in a step, and then supporting a skipped build status? Or am I missing something?
Iâve been using that approach for a while. There are problems since git clone fails for various reasons. Itâs also slow. Every change triggers all the builds and they must perform a full clone.
On buddybuild with native support, these builds arenât triggered at all. Thatâs helped dramatically with performance and build stability.
Quick update: this feature is scheduled in the current sprint and weâre working on it, should be available in the upcoming weeks. Will update you here once itâs ready!
Weâve released the mono repo support feature as Selective Builds. You can find this option on the Settings page of your application at the Enable Selective Builds section. You just need to toggle the switch and then add your change paths to the list