Create Environment no longer creating deployments
I have a github action I created which would use the api to call createEnvironment which itself would do things to setup ephemeral PR environments however the github aciton is now failing. Upon inspecting it it was because this line in my github action is failing https://github.com/Faolain/railway-pr-deploy/blob/main/index.js#L240 (wherein it checks for a deployment status), however this always used to work. I haven't changed this action in quite some time and PRs from the last few days were functioning. This line expects a deployment to already exist which was always taken care of by https://github.com/Faolain/railway-pr-deploy/blob/main/index.js#L376 . Do deployments need to be explicitly done now after an environment is created?
GitHub
railway-pr-deploy/index.js at main · Faolain/railway-pr-deploy
Contribute to Faolain/railway-pr-deploy development by creating an account on GitHub.
54 Replies
Project ID:
7b1d4989-a0d3-4bb1-98de-a5372becb82d7b1d4989-a0d3-4bb1-98de-a5372becb82d
I was able to confirm there were no deployments after the environment was created here on the dashboard whereas normally there is always an autodeployment on this dashboard when an environment is created programatically
Also to note changes to env no longer auto deploy as well.
on the downside the api has changed like you predicted it would, on the bright side, now you can add the variables before the first deploy!!
interesting thanks Brody yeah like the conversation we had however long ago
just need to edit the action now
unfortunate but I see this as a win, no more failed initial builds!!
Was circling back on this trying to access https://backboard.railway.app/graphql/v2 but I see this page
@Brody do you see the same thing?
oh wow I do see the same thing
do you get blocked when trying to make actual authenticated api calls?
nope
only when trying to look at the hosted schema docs
(which I kind of need to figure out what I need to do to edit my github action 😅 )
introspection doesn't work?
ah I do see access to the overall schema within my graphql client
but would still be nice to do so via the website
I didn't think you could do it via that link? before it showed some generic Apollo page
is this what you want instead? https://railway.app/graphiql
hm strange, had the other page bookmarked and it worked, false alarm maybe?
but yes this is the page I was looking for
prob user error 😅
for as long as I've known that v2 api link has returned a default Apollo page
it happens
another stupid question, is there a canonical way to "deploy", previously I was using the
serviceInstanceRedeploy mutation but since there are no deployments I expect this isn't suceeding or redeploying anything. How does one create that "initial" deploy with the new default railway behavior?depends, do these services without deployments come with the github and branch linked?
yep ( or rather they did before)
what mutation does the deploy button perform, maybe that will work for you?
It appears to be
which doesn't appear to be documented in the apollo schema docs?
oh that's probably on the internal schema only for right now
so then how do we create a deployment now programatically?
you dont want to use the internal api?
oh so is this the canonical way of doing it? I just don't want to try an endpoint that could be janky/not work/change soon again
fwiw this has broken ephemeral PRs and it's a bit hard trying to reverse engineer what the team did, as now branches do not a) use source branch upon environment creation (previously was using deploymentTriggerUpdate and this worked) and b) no longer deploy either
the team should version the api or at least communicate/document what behaviors will be changing with a migration plan
oh so is this the canonical way of doing it?if the dashboard does it, yes
I just don't want to try an endpoint that could be janky/not work/change soon againwell it seems like even queries that have been around for a long time can change
he team should version the api or at least communicate/document what behaviors will be changing with a migration plani agree they should communicate this somewhere, but i cant see how they could version it, since major platform behavior has changed that is no longer supported, cant version the api if the platform no longer supports it
many apps have versioned graphql endpoints fwiw, and deprecation gives enough time for users to migrate usually
have a few open PRs atm and scrambling to get this fixed (and I know others now also use my gh action which makes this more pressing too)
would it be possible for a member of the team to take a look at the action and suggest the changes that need to be made instead of me guessing what needs to be done?
what are we guessing at? you need to add the applicable variables and then trigger a deploy, thats all that looks like needs to be done from my perspective?
For example are deploymentTriggerIds still used? Previously I would do
updateAllDeploymentTriggers which itself would call deploymentTriggerUpdate for each deployment and that would switch the branch to the correct github branch. Now despite this running, and then manually deploying this has not occurred. Additionally the env_vars which were previously added with await updateEnvironmentVariablesForServices(environmentId, serviceInstances, ENV_VARS); doesn't work now (the env variables are old)you would want to used staged changes the same way the dashboard does it
so does this require other calls
im not sure, you would have to look at what calls the dashboard makes
would it be possible for a member of the team to take a look at the action and suggest the changes that need to be made instead of me guessing what needs to be done?
ill be honest, i have no problem flagging the team for you, but you would very likely be able to solve this before they reply as they are very busy with database migrations and other new features that are in the works
I would really appreciate that, just since they are the most familiar they would likely understand relatively quickly what I need to do. (for example I have no idea how to do staged changes or what that implies or what other gotchas might exist) https://github.com/Faolain/railway-pr-deploy/blob/main/index.js
GitHub
railway-pr-deploy/index.js at main · Faolain/railway-pr-deploy
Contribute to Faolain/railway-pr-deploy development by creating an account on GitHub.
will do, give me a min to write an eye catching reason
Thread has been flagged to Railway team by @Brody.
like i said, please dont wait up
I will begin to list some of the issues here because this isn't quite something I can guess or reverse engineer
tagging in @jr to take a look!
1) Previously doing
would create an environment based on/forked from the source environment and display correctly in the GUI with branches made from a source environment "nested" under the source (staging) environment. Now as with
insomnia-tst-2 (just created) they are no longer nested under staging (ephemeral PRs are made based off of staging) This is confirmed both in the github action and by calling API. Are creating forked branches no longer supported?
I am taking a look at this now. Just to confirm, the main issue is that when a new environment is created, nothing is initially deployed?
the services not auto deploying is good so that custom environment variables can be added to the service before the first deploy, but this was what they where mainly asking https://discord.com/channels/713503345364697088/1202276121450926182/1204112043423301673
Everything else should be the same. The main issue is that by default when a new environment is created, there are no services or triggers deployed to it since the changes are staged. That is a breaking api change that was not intended. What we can do is make the old behaviour the default and deploy immediately, while the dashboard will still stage the changes allowing variable edits before the first deploy
for their intended purposes the missing initial deploy is actually beneficial
the changes still need to be applied to the environment. otherwise there are no services/triggers
yeah that's what I said, they'd need to do what the dashboard does, but make the applicable api calls
from my understanding, this is exactly what faolain is trying to do https://twitter.com/thisismahmoud_/status/1754559792834605502
Some updates to the API that will soon go live
- The default behaviour for
environmentCreate will be to apply and commit the changes. This is in line with the old behaviour. So you will be able to pass the sourceEnvironmentId and have a new environment created with the same configuration as the source
- A new stageInitialChanges argument that will stage all the changes first, before committing anything (this is what our dashboard will use)
- A new skipInitialDeploys argument that will prevent any services in the new environment from being initially deployed
I've tested the flow that the GH action uses and think all behaviour is restored, but am happy to work with you in making sure everything is running smooth. Apologizes that there was an unannounced breaking change in the first place, that was not our intention.Really appreciate it @jr!
Yeah so there were a few things that broke after the update (as I got to look more deeply into this)
1) environmentCreate is not creating a fork of the base environment seemingly or is not doing so when looked at on the GUI. The environment appears to be standalone and not nested or "forked" from the
srcEnvironmentId.
2) Applying deploymentTriggerIds (which I would use to set the source environment branch for that new forked env) also no longer would work, aka the new environment would still point to dev instead of the branch set in the deployment trigger. As you mentioned this is likely because there are no services or triggers deployed because the changes are staged
3) Applying env variable changes also stopped working likely due to the same reason from above.
Do you know if the changes are live? For reference I just closed and opened a PR (which triggers automation) which was using the previous Github Action workflow and it seems like nothing has changed (in that functionality is still "broken")1. The nesting in the interface no longer exists. You can still create a fork by passing in the
sourceEnvinronmentId and the new environments config and variables will be the same as the fork
2. This will be fixed if the changes are applied right away (which will be the default)
3. Same as 2
The changes will be live in ~20ish minutes. Just going through CI now and then will be mergedperfect thanks so much @jr ! really really appreciate it
just checked and these changes worked, only a very minor comment on this is it possible to preserve in the GUI what the source was? Attached is an image of environments forked using a
srcEnvironmentId showing it nested under staging (where it was forked from). But now the new environments although correct do not display visually the same anymore within the GUI
pr-237 just deployed by me (previously was nested under staging as pr-253 is)
Sorry for the long delay.
Unfortunately that part of the environments UI is not coming back. Environments can pull in changes from any other environment now so showing it as a "fork" doesn't make sense since that relationship doesn't represent anything after the first creation