With a linked Github repo we have master branch deploys working and also a draft PR has correct preview deploy integration, Has worked for a while now.
However, I just created a new PR with a branch based on the working one but no Netlify integration appears in the PR, the Netlify checks are not run on commits and no builds are ever triggered in netlify.
What could be wrong. I’ve checked all the site settings against other working ones. I also relinked the GitHub Repo.
There seems to be no way to manual run a build for specific branch either, just production or existing builds
Oh, I just had a thought. Perhaps the branches in question are “target” branches not source as I had assumed for PRs. My conceptual model is a little muddled give all the option descriptions. Beingvtaeget would examine why PRs to main work with none set given that is enabled for may deploy.
So I have got to the bottom of my confusion and I’m sharing it in case others get same or it helps improve the product. This has long confused me
So the root cause is that the GitHub integration adds behaviour not mirrored in the deployment settings. namely the builds are run not only commits to the production branch also commits to other branches that are the source branch in a PR merging to the Production branch.
So in this setup
production branch: main
dev branch in a PR merging to main: dev
Branches setting - none (Deploy only the production branch)
Any commits to dev get a preview build. Even though we selected the options saying only commits to production! Confusing. It’s the GitHub integration adding behaviour.
The if I add a new branch called “suggest” with a PR to dev I want preview builds when that new branch is committed to.
By the above behaviour I should not need to say “suggest” is a branch I want commits to trigger builds. It’s the source branch of a PR. Hence my confusion. I’d expect to say “dev” branch should be built when PR source branches get commits.
But I see that only makes sense when GitHub integration is enabled, and the build settings panel doesn’t reflect that.
So is production branch special and it’s the only one that gets builds when it’s the target of a PR? Or can other branches be set up to do the same. Perhaps if the production branch setting only controls the target in a PR behaviour it can be renamed and take a list of branches to create preview builds for?
So, for now I’ll explicitly add the “suggest” branch as suggested by @coelmay even though that feels odd. And always we always have a PR for work so it is visible to the team, easy to see changes and allows discussion. Thus builds on commits to branches not in a PR are to be discouraged.
Bump! Can anyone find a solution or else report missing feature to dev?
Another issue I just hit is that some git hub actions MUST live in the default branch - which will be the same as the Netlify production branch. ‘main’ or ‘master’ in most cases.
When the action yml file is update we definitely do NOT want CI?CD to be triggered as it does not depend in the github action.
I can find no way to disable the build for specific files or a specific commit. I want other files to trigger the CI/CD build and so other developers who are using the repo.
Perhaps the github default branch could be set to be different to the netlify production branch - but that’s getting a bit it complex. I reality the build should not depend on some files. Can that be done?
To answer my own second question there is the netlify.cfg ignore builds setting.
I find the “rough” a bit worrying " Here’s an example of an ignore command that’s a rough approximation of the default ignore builds behavior. You can add to or adjust it to update the default check". Would be reassuring to invoke the exact default behaviour and modify it by adding file(s) to ignore.
Here’s how l ignore all GitHub workflow files for build
[build]
# always ignore github workflows
# for the obscure pathspec syntax see https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec
ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF -- ':(exclude).github/workflows/'"
The deploy still runs (and I guess is counted towards limits) and clutters up the lists but it is marked as ‘cancelled’ after quickly finishing.