observablehq
Deploy option to enable continuous deployment
Running notes
- Whether you build locally or in cloud, the deploy method ends with pollForProcessingCompletion. In the local case, that just means uploading files; in the cloud case, it means doing a whole cloud build. Should we have the same timeout in both cases?
- Currently this prompts you to enable continuous deployment even if your project directory is ineligible, so you know it would be an option if the criteria were met, and so we can provide informative errors about why it's not available. Sound good?
- Once your continuous deployment setting is saved, do we ever prompt you about it again? Is there a command to turn it on, or do we instruct you to edit deploy.json?
- The continuous deployment setting is a property of the source code, but the GitHub connection and build environment are properties of the data app in our database, i.e. the “deploy target”. Those can change independently: e.g. you might unlink GitHub without touching the code, and your next deploy command will fail.
- State like “continuous deployment is enabled but you don’t have GitHub linked”
- Can’t tell when it changed though
I think this is ready for review again!
Purpose
The idea is that, when a user runs yarn deploy, they’re given the option to enable continuous deployment (persisted in deploy.json). If they do, we link the repo and immediately kick off a cloud build; the command exits when the build completes (w/ a link to the deployed app) or fails, same as with a local build. Thereafter, users shouldn’t really have to run yarn deploy anymore, since they can just push to GitHub — but if they do run yarn deploy again (e.g. to pick up new data), it kicks off another cloud build.
Note that the deploy command ensures you’re currently in the same repo and branch that’s configured in our database. (We could go further and add some info to the API response so we can check that the refs match.) The idea is that you’re trying to deploy the state of the repo you’re in, not just controlling the data app management console from a command line in a repo in some different state.
Note that currently there’s no CLI command to change the continuousDeployment setting once set; Fil suggested we could have a separate command to review all settings in deploy.json, but I’m inclined to save that for another PR.
Implementation
When run manually from the command line (as opposed to in our cloud build environment where we pass in an existing deploy ID), running deploy calls startNewDeploy. It calls getDeployTarget to find out where it’s deploying to; in this PR, I’ve updated getDeployTarget to check the continuousDeployment option; if it’s not present, we prompt the user whether to enable it. Back in startNewDeploy, if continuousDeployment is on, we call validateGitHubLink and then cloudBuild; else we build locally and deploy as usual. (validateGitHubLink checks that you have an authorized and matching repo linked in our database; if not, and you’re in a repo with a GitHub remote, we link it, or prompt you to go to the web (to a new screen added in https://github.com/observablehq/observablehq/pull/18314) to authorize it if necessary.)
This adds dependencies on a couple API routes:
- /cli/github/repository?owner=${props.ownerName}&repo=${props.repoName}, to check the authorization of a single repository
- /cli/project/${id}/environment, to set a GitHub link; this endpoint could potentially be rolled into the post project edit endpoint
- /cli/project/${id}/build, to initiate a cloud build & deploy of a project
I wonder if we could/should provide a post-commit or post-push hook that would remind the user that their push is going to trigger a build (and where to see the logs etc). (I was just editing a project and could not remember if I had already enabled CD on it.)
