2 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
2 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?
2 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.
2 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=previewCustom 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?