Is it possible to trigger a preview build via a webhook.
Hi! You can set up a build hook you can use to trigger a new deploy. Our Build & Deploy document has some more details. You’ll need to make sure you have a git repo linked to your site if you don’t see the option in your settings. Hope that helps!
Hi! I don’t think this fully answers the question.
The docs say we can trigger a branch deploy via webhook. (https://www.netlify.com/docs/webhooks/#incoming-webhooks)
The docs don’t mention triggering a deploy preview via webhook.
Our use case would be to run some CI steps in GitLab - testing, performance, etc., before starting Netlify’s build+deploy process.
I could wire this up for branches (using the webhook) but it doesn’t appear this is possible for merge request deploy previews, unless the docs are out of date.
Ah, right, you won’t be able to trigger a deploy preview using build hooks. You can only define what branch a build hook will trigger. However a deploy preview is essentially the same as a branch preview, just with a different context, so if you know that a branch has a PR, you can trigger a deploy for that branch and that would be the same as far as the content is concerned.
Did you have a particular usecase where you need to trigger a deploy preview specifically?
My understanding is that a deploy preview is a preview of what the site would look like after the merge. So a branch build would only include the contents of that branch, the preview deploy would include the merged contents of the current branch and the target branch. Thus triggering a branch deploy wouldn’t be the same as a merge deploy. Is that understanding correct?
The use case - for both branch deploys and deploy previews - would be to run our GitLab pipeline (tests, etc) before actually doing the deploy.
Ah yes, I wasn’t very clear with my explanation. You are correct that a deploy preview builds the pull request which isn’t always exactly the same as the branch.
In this case, the simplest (possibly only) option would be to build your site in your pipeline and deploy using our CLI.
Right. In that case we lose the consistent naming scheme for branch and PR deploys.
In GitLab CI, the “environment url” (used to provide a direct link to the app for that PR or branch) has to be built from things that are known before the deploy step starts (branch name or PR number should work), but Netlify manual deploys only get a random string because they’re not linked to a branch or PR.
I’m thinking about how this would be implemented, how would you pass the deploy preview information in to netlify? would you get the PR or MR number from gitlab and send that in the buildhook? I want to get a feature request filed for this.
You can get a lot of information from GitLab pipeline’s environment variables (full list here) in the context of a build.
You can also build steps that run only in specific contexts (particularly, branches or merge_requests).
Netlify also has read access to the repository so given a commit SHA I wonder how much could be inferred about the build context? I.e. is the commit in any active merge requests? Is it in a branch? If yes to either, build as appropriate.
If something like that’s not possible, this would probably cover the basics for me:
For a branch deploy you would trigger the build hook with type=branch and branch_name=$CI_COMMIT_REF_NAME
For a merge preview deploy, type=preview_deploy and merge_request_id=$CI_MERGE_REQUEST_ID
For production, type=production (similar to current
netlify deploy --prod)
Thanks for that detail @df-1! really appreciate it. I got a request filed to add this functionality. I don’t have a timeline or any details but when we know more, we’ll let you know.
+1 for this feature!
+1 for this feature request.
Any progress on this feature request? ETA?
Use case from a marketing/content integration perspective:
Use Case: Marketer wishes to preview their content changes in the context of a given development branch that is already setup (via Netlify) for deployment. Marketer wishes to call a sanctioned Build Hook and specify the type as Deploy Preview.
+1 for this feature request.