Detect GitHub/GitLab CI test status to trigger auto deploys | Feature Requests

Detect GitHub/GitLab CI test status to trigger auto deploys

planned

Richard Gill

You can use Render Deploy Hooks to trigger a build from an external CI service like GitHub Actions or CircleCI.
https://render.com/docs/deploy-hooks
It would be nice to automate this process based on CI status check events that GitHub already emits on the repo.

August 22, 2019

Anurag Goel

Pinned

This can be achieved today by turning auto-deploys off and using Deploy Hooks: https://render.com/docs/deploy-hooks. We are still planning to add it to our native GitHub/GitLab integrations.

Ciao

can i use travis ci to auto deploy ?

geoff.tidey

Any updates Anurag Goel? This ticket is

three

years old & third most voted feature request at this moment in time.

Bèr Kessels

I'm using Github Actions to run acceptance tests over the deployed instance. This is somewhat reversed from what is proposed here. 
FWIW, what I need
 is the following:
* CI runs linter & unit tests
* if green, CI triggers a build on acceptance env of Render.
* when deployed, CI runs acceptance tests over the network: client on CI, server on render acceptance env.
* if green, CI tags the release on GH.
In render.com I then want another interface (or CLI-tool) that allows me to deploy any such tagged release to production env on render. Full CI/CD might do this last step automated as well.
Except for maybe the last, this is a rather common CI pipeline: run unit tests, deploy to a staging env, acceptance-test that staging env, mark build as passed/failed.
Some ways this could be achieved, none of which work currently due to missing pieces on render.com (or needing to write coupled/complex code)
* As per this here feature-request: there is no easy way to say: deploy only after step or pipeline x has passed on the CI.
* I cannot easily trigger a release (using a webhook) and then wait for it to be deployed from my CI. The gh-action by bounceapp has a bug, but would do this. Ideally the health-check would be used for this.
* render cannot call a webhook (on github) after successfull release which would trigger another CI-pipeline and/or the next step in the pipeline - I must now build this into the app and/or the boot script instead. Maybe I'm missing something?
* Render seems to have no easy way to reset or drop+create the database around each integration test - I must now build this into the app. Maybe this is planned in the API?

Khiman Louër

Anurag Goel Any news on this feature ?

We would really love this :)

Georges Gabereau

This would also help integrate nicely with Github Actions. I'd really love to see this implemented.

connor

Out of interest - this is marked as

Planned

- I was wondering if there's any information available as to what the plan is?

We're currently using the Deploy Hooks with Circle CI and it's working well!

Anurag Goel

connor: The plan is to automatically detect CI check runs in Circle/Travis and optionally wait to deploy until the checks succeed.

Lloyd Chang

Hi Anurag Goel,
Would the plan look like:
Step 1: Render: Events: Get CircleCI pipeline by ID
Step 2: → CircleCI returns "state": "created"
 to Render: Events
Step 3: → Render: Events: Deploy
?
References:
• https://circleci.com/docs/api/v2/index.html#operation/getPipelineById
• https://discuss.circleci.com/t/pipeline-states/39687
• https://circleci.com/docs/api-developers-guide/
Thank you.

Marc Köhlbrugge

Here's a work-around you can use right now:

Create a new branch called "production".
Set up Render to auto-deploy from that branch (instead of "master")
Configure your CI such that when the build passes, it pushes "master" branch to "production"

The added benefit of this approach versus just deploying from master, is that you know for a fact* what code is live on production. With the traditional approach you might end up with a master branch that does not pass and thus is no longer a representation of what code is running on production.

* except of course, if the deploy itself failed

geoff.tidey

Unfortunately this breaks review apps. As currently they must be branched off the render deployment branch.

ouuan

This shoud be optional so that users can use Render as a CI test.

Nicos Maris

Same for gitlab Merge Requests

Anurag Goel

This can be achieved today by turning auto-deploys off and using Deploy Hooks: https://render.com/docs/deploy-hooks. We are still planning to add it to our native GitHub/GitLab integrations.

Richard Gill

Anurag Goel: This is true - will you still be adding it built into the platform? Heroku has it and it's pretty useful!

Anurag Goel

Richard Gill: Yes. Still planned. I'm guessing the integration is with the GitHub Checks API?

Richard Gill

Anurag Goel: I think so yes, it's agnostic to the actual Continuous Integration tool you're using. (I use Circle, but would also work with Travis etc.).

Anurag Goel

Richard Gill: Sounds good, and yes this is definitely coming soon.

Štefan Ľupták

Anurag Goel: this solution doesn't work when using PR previews. I don't have the webhook URL available inside the test+deploy GitHub Action, since this PR environment was created dynamically.

Štefan Ľupták

Anurag Goel any tip on how to achieve this?

Lloyd Chang

Hi Richard Gill,
When your time permits...
Sorry, I don't fully understand the clear division of responsibilities between GitHub, CircleCI, Render in your Developer Productivity workflow.
Is Step 1: GitHub the SCM, Step 2. CircleCI the CI, and ... Step 5. Render the CD?
In other words, the following examples:
----
Step 1: SCM (Software Configuration Management
Step 2: → CI (Continuous Integration)
Step 3: → SCM
Step 4: → SCM
Step 5: → CD (Continuous Delivery / Deployment)
----
Step 1: GitHub (SCM)
Step 2: → CircleCI (CI)
Step 3: → GitHub (SCM)
Step 4: → GitHub (SCM)
Step 5: → Render (CD)
----
Step 1: GitHub Commit in Pull Request Source
 Branch
Step 2: → CircleCI Pipeline ID
Step 3: → GitHub Status Check ID
Step 4: → GitHub Commit in Pull Request Destination
 Branch
Step 5: → Render Events ID
----
Step 1: Preview
Step 2: → Preview
Step 3: → Preview
Step 4: → Production
Step 5: → Production
----
Richard Gill wrote, "nice to automate this process based on CI status check events that GitHub already emits on the repo."
• To be clear: Are you asking for Render to deploy before
 a GitHub Pull Request has been merged?
• Specifically, are you asking about Steps 3: Preview and 4: Production above?
• If yes, then a follow-up question — Is your context for a Preview Environment in Render's Team, Organization, and Enterprise plans at https://render.com/docs/preview-environments ?
• If not, and if your context is for a Production environment, then the feature request doesn't fully make sense to me.
• If the context is a Production environment, then I believe what is needed is an auto-merge in GitHub based on the following:
An auto-merge in GitHub can either be:
• The GitHub Action: automerge-action at https://github.com/pascalgn/automerge-action
• The GitHub Auto-merge Feature at https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request
At first glance to me, it seems like you may be asking for "faster horses" from Render in Step 5... but you may actually be asking for an "automobile" from GitHub in the form of an auto-merge in Step 4.
Situationally, I want to make sure that we don't have a situation like the adage, "If I had asked people what they wanted, they would have said faster horses." associated with Henry Ford and Ford Model-T automobiles.
Hence my questions above for clarification about Steps 1, 2, 3, 4, 5.
Richard Gill, thank you for your time!  Take care!

→