#How do PR Environments Work?

1 messages · Page 1 of 1 (latest)

noble granite
#

https://docs.railway.com/guides/environments#enable-pr-environments

these docs are pretty sparse on exactly how the PR environments work. I'm looking for some help in understanding from a functional perspective what Railway does when it consumes a pull request webhook from GitHub.

Here's what I'm trying to do:

  1. Pull Request is opened
  2. A new project (or is there a cleaner way?) is created with postgres and redis
  3. A container is built using railpack for the repo branch
  4. Custom start "pre-start" scripts (database migration and staging seed) are run
  5. The domain is generated and reported back to the PR
  6. Everything is configured as serverless
  7. When the PR is closed, the entire project/services are destroyed

Alternatively, we could use a single postgres + redis for all preview environmetns and just create a new database against that single postgres instance, but we would still need to teardown the DB name, etc on PR close/merge.

Any pointers?

Using Environments | Railway Docs

Manage complex development workflows via environments in your projects on Railway.

silk sapphire
#
  1. We could create a duplicate environment for you under the same project, based on whatever base environment you have set in your project settings.
  2. As long as that's what's used for the service in the base environment, that is what will be used in the PR environment.
  3. You can see that via PR environment overrides.
  4. As long as the service in the base environment has a service domain, the service in the PR environment will also have a domain, and we will show that in a table that our bot makes in a commit on the GitHub PR.
  5. That can also be set via PR environment overrides.
  6. That is exactly what happens.
noble granite
#

@silk sapphire re: #2, how can i configure that? i.e. what tells railway to create a dup environment?

silk sapphire
#

That's just how the system works, do you have PR environments enabled?

noble granite
#

ah ok ok. Cool. I don't.

Right now i can't use railway on prod primarily because of HIPAA, so I'm looking into setting this up just for the preview side of things.

silk sapphire
#

I imagine you can use Railway and set up all the applicable infrastructure; you just cannot store real health data. Mock data would be fine.

noble granite
#

Couple things I need to solve for:

  • Run a seed script. Preferable the seed script will post back to github with the resulting test URLs.
  • Set PYTHON_ENV=preview
  • Custom set of variables. I don't want to use the exact same variables as the production environment
  • I restrict origins on the API server. This is set via an ENV var (comma-separated list of valid origins). I'd like to update this env var for the environment after the environment is created.

Any tips on this / patterns you've seen for this use case?