Adding to this, I’d like to describe my dream workflow and you can see the feature requests that it requires.
I have a monorepo, I would like to use GitHub Actions to determine when to trigger a Netlify build. This includes a mix of which branch is pushed (
on > push > branches in GH Actions syntax) to and which files have changed (
on > push > paths in GH Actions syntax).
When I trigger a deploy, I’d like to specify the context and the commit it should deploy as. Currently I can only specify a branch. Moreover, this workflow requires to disable the production branch in Netlify (I’ve set it as
none) but then my “actual production branch” build triggered by the hook becomes a branch deploy, which messes around with the subdomain.
Since branch deploy are limited to subdomains of the main domain, I cannot use this bag-full-of-tricks workflow unfortunately. In the first place, if you have www.company.com and app.company.com on Netlify you’re also stuck with dev and staging envs like dev.app.company.com and staging.app.company.com. I use multiple sites on the same repo with different production branches to get around this issue.
All in all, I’m aware this might be a more advanced setup which needs to be balanced with the ease of use people love Netlify for. And it falls in the hands of the Netlify team to choose their tradeoffs. But I thought it might be worth to detail the dream workflow I have, as input to the team.
- more options in build hooks: commit, context
- less constraints with branch deploy subdomains
Goal: more control over when builds happen to avoid unnecessary builds.
What’s my status quo for now? I still love Netlify and feel thankful for the time it saves me, and I over build my frontend and functions whenever another part of my monorepo or docs change.
Hope this helps.