4 months ago
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:
- Pull Request is opened
- A new project (or is there a cleaner way?) is created with postgres and redis
- A container is built using railpack for the repo branch
- Custom start "pre-start" scripts (database migration and staging seed) are run
- The domain is generated and reported back to the PR
- Everything is configured as serverless
- 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?
8 Replies
4 months ago
- We could create a duplicate environment for you under the same project, based on whatever base environment you have set in your project settings.
- 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.
- You can see that via PR environment overrides.
- 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.
- That can also be set via PR environment overrides.
- That is exactly what happens.
@Brody re: #2, how can i configure that? i.e. what tells railway to create a dup environment?
4 months ago
That's just how the system works, do you have PR environments enabled?
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.
4 months ago
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.
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?
It looks like PR environment overrides does not enable custom environemtn varible overrides to be set?