Hi folks! Buildasaur has been working great for our feature pull requests but I'd like to improve more of our release automation and think that would be hard to do with the tool as-is. Before I sink time into a pull request specific to my needs I'd love to hear if any of you would like the same thing, or something similar to solve your own problems.
Today we have Buildasaur manage Bots for each pull request branch. We separately manually maintain a release bot watching a release branch for App Store submissions. That works but leads to a lot of merges into release. We get one merge per upload (e.g. reacting to invalid binaries or app rejections from Apple or Test Flight feedback) rather than per-release.
If we assumed a GitFlow branching model we can imagine maintaining a Bot per release/* branch which would simplify our process for triggering and watching builds and managing tagging releases.
I think I'd like to have the ability to define branch name patterns in our Buildasaur watchers. Keep the existing "match all PRs" as the default but be able to override that to match release/.* or feature/.* or whatever pattern fits your workflow.
What do you all think? Is it important to be able to watch non-PR branches as well? Do you want to differentiate on the destination branch of a PR? Are there other ways to solve this I'm not considering?
Hi folks! Buildasaur has been working great for our feature pull requests but I'd like to improve more of our release automation and think that would be hard to do with the tool as-is. Before I sink time into a pull request specific to my needs I'd love to hear if any of you would like the same thing, or something similar to solve your own problems.
Today we have Buildasaur manage Bots for each pull request branch. We separately manually maintain a
releasebot watching areleasebranch for App Store submissions. That works but leads to a lot of merges intorelease. We get one merge per upload (e.g. reacting to invalid binaries or app rejections from Apple or Test Flight feedback) rather than per-release.If we assumed a GitFlow branching model we can imagine maintaining a Bot per
release/*branch which would simplify our process for triggering and watching builds and managing tagging releases.I think I'd like to have the ability to define branch name patterns in our Buildasaur watchers. Keep the existing "match all PRs" as the default but be able to override that to match
release/.*orfeature/.*or whatever pattern fits your workflow.What do you all think? Is it important to be able to watch non-PR branches as well? Do you want to differentiate on the destination branch of a PR? Are there other ways to solve this I'm not considering?