3
votes

I am using Travis CI to build a site from this bookdown GitHub repo and deploy to the gh-pages branch. This approach mostly works, but I would like to use Netlify to show draft previews of pull requests too. So far, the Netlify deploy notifications are reacting to the incoming source files, not the HTML files that Travis is building. Netlify previews come in too early and the pages are blank.

enter image description here

Edit: the workflow

In this specific project, we have a bunch of source files that eventually generate the HTML files for the site. The master branch has the source only, and the gh-pages branch has the HTML only. I am using Travis to compile the HTML using the source on master and then push it to gh-pages. This works great for my own development because it automates the 10-minute site-generation process.

I was hoping to use Netlify to make enable site previews for pull requests, both from collaborators and external volunteers from the open source community. I picture something like the following.

  1. An external developer forks the source from the master branch of https://github.com/ropenscilabs/drake-manual and makes some changes.
  2. The developer then submits a pull request to merge the changed source files into the upstream master branch. The HTML was not necessarily generated in this process.
  3. Travis CI builds the HTML files from the fork, but since the pull request was not approved yet, it does not commit to gh-pages or push to GitHub. Instead, it sends the HTML files directly to Netlify.
  4. Netlify receives the HTML, generates a preview, and notifies the GitHub pull request with an incominb webhook.

I realize that security restrictions on Travis environment variables make part of this impossible, and rightly so. But this is the kind of automated deployment I would like to reach eventually.

1

1 Answers

3
votes

Disclaimer: I work for Netlify

Netlify's build notifications can only reflect Netlify's builds - won't be able to take Travis' status into account in our notifications if that other build runs in parallel. Perhaps you can reconfigure our CI to instead of using github's commit-based webhooks to notify Netlify to build, use one from Travis to initiate the build on Netlify? Then Netlify's build would start after theirs is over. To do this, you can remove the build hook from GitHub and instead use an incoming webhook which you can configure one-per-branch, though you'd maybe need some logic at Travis to decide which one to notify if you use many branches. You can configure those via API programatically (https://open-api.netlify.com/#!/default/createHookBySiteId) but we'll be happy to advise on a more step-by-step API usage in the helpdesk

If that's burdensome (e.g. you have a lot of short-term-use branches), then I understand it's probably not a great solution. I might solve the problem socially in that case and just train my dev team not to look at the deploy preview until the Travis checks complete :)

Since the use case evolved and I gave a better answer in the comments, I'll describe that here:

You can instead choose to deploy the files that Travis has build using our command line utility netlifyctl. This takes a copy of your site and sends the files up to us, and is scriptable. You can choose to immediately publish those results ("tests passed on Travis, we're ready to go live") as netlifyctl deploy or choose to publish a draft deploy that you can browse at the deploy preview URL (https://hash--sitename.netlify.com) using netlifyctl deploy -d.

This doesn't address the original concern around commit status notifications, since we only send those for git-backed deploys that we build, but it does allow you to publish known-good deploys and netlifyctl deploy does output that URL (https://hash--sitename.netlify.com) when run so that you could "do something" with it like craft a notification that is also generated from the process that builds + sends to netlify for e.g. slack or email.