How to spin up a vm with custom url on pull requests

Hello all,

I was hoping someone can shed some light on a topic that I have yet to find much information around. It also might just be that I’m not looking in the right places.

What I’d like to do is spin up a virtual environment with a custom URL whenever a pull request is created for review purposes with clients and or other team members. Is this even possible?

It’s possibly in principle, the details will vary a lot depending on your infrastructure. In general, you can do a build and deploy the result to a test environment. For example, if you have a Kubernetes cluster you could log in to that and bring up a pod.

A few things to consider:

  • How will the deployment be stopped? E.g. if you deploy to a cloud hoster you probably don’t want to be billed for it indefinitely. :wink:
  • Could deploying code from a possibly untrusted pull request cause security issues?
  • Deployment will likely need credentials, probably via secrets. If you want to allow pull requests from forked repositories to trigger deployments you may need to use the pull_request_target event.

Thank you for your response. Just to answer some of your feedback.

  • How will the deployment be stopped? E.g. if you deploy to a cloud hoster you probably don’t want to be billed for it indefinitely

    • Very good question and point. I was under the impression that this can all done within the Github ecosystem. These test environments would be included?
  • Could deploying code from a possibly untrusted pull request cause security issues?

    • For our purposes we’d be working with private repos and only approved team members would be able to create a pull request
  • Deployment will likely need credentials, probably via secrets. If you want to allow pull requests from forked repositories to trigger deployments you may need to use the pull_request_target event.

    • This is great to know. Thank you

I guess i’m still a bit confused about where this would need to occur? Is this a combination of Github Actions and a hosting service? Or can this workflow all live within Github?

Update
Came across these tools:

If there are others would you mind sharing. Thank you!

Github provides hosted runners for Actions workflows, but those are not publicly reachable as such. Build artifacts can be uploaded within Github (including as releases), but application deployments generally need to happen outside. I’ve read about services where you have the Actions runner connect to them and then can tunnel into it via that services, which may be useful for debugging (but not something I have used). But that’d still be via a third-party service.

Either way the usage limits for Github-hosted runners are probably not what you want for a manual test environment, especially the part where jobs are cancelled if they run longer than 6 hours. Another thing is that you mentioned using private repositories, which means you will be billed for job run time by the minute (with some amount included depending on you account type). Finally I’m not sure if that kind of hosting would be within the ToS on Actions Usage, but if that’s the only remaining issue you should ask Github staff about it. :wink:

In summary, I’d recommend using Github Actions for automated tests, and (if they pass) deploy to a suitable hosting service for manual testing or customer review.

I haven’t used any of the services you linked (nor any similar one), but if they do what the websites promise either of them should work for what you described.

2 Likes