Railway•5mo ago

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

Percy•5mo ago

Project ID: 7b1d4989-a0d3-4bb1-98de-a5372becb82d

Faolain•5mo ago

7b1d4989-a0d3-4bb1-98de-a5372becb82d

Faolain•5mo ago

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

Faolain•5mo ago

Also to note changes to env no longer auto deploy as well.

Brody•5mo ago

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!!

Faolain•5mo ago

interesting thanks Brody yeah like the conversation we had however long ago just need to edit the action now

Brody•5mo ago

unfortunate but I see this as a win, no more failed initial builds!!

Faolain•5mo ago

Was circling back on this trying to access https://backboard.railway.app/graphql/v2 but I see this page

Faolain•5mo ago

@Brody do you see the same thing?

Brody•5mo ago

oh wow I do see the same thing do you get blocked when trying to make actual authenticated api calls?

Faolain•5mo ago

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 😅 )

Brody•5mo ago

introspection doesn't work?

Faolain•5mo ago

ah I do see access to the overall schema within my graphql client but would still be nice to do so via the website

Brody•5mo ago

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

Faolain•5mo ago

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 😅

Brody•5mo ago

for as long as I've known that v2 api link has returned a default Apollo page it happens

Faolain•5mo ago

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?

Brody•5mo ago

depends, do these services without deployments come with the github and branch linked?

Faolain•5mo ago

yep ( or rather they did before)

Brody•5mo ago

what mutation does the deploy button perform, maybe that will work for you?

Faolain•5mo ago

It appears to be

operationName
: 
"environmentPatchCommitStaged"
query
: 
"mutation environmentPatchCommitStaged($environmentId: String!, $message: String, $skipDeploys: Boolean) {\n  environmentPatchCommitStaged(\n    environmentId: $environmentId\n    commitMessage: $message\n    skipDeploys: $skipDeploys\n  )\n}"
variables
: 
{environmentId: "f561f68e-d7ff-4aad-ab8b-3cbba0a56340", skipDeploys: false}

operationName
: 
"environmentPatchCommitStaged"
query
: 
"mutation environmentPatchCommitStaged($environmentId: String!, $message: String, $skipDeploys: Boolean) {\n  environmentPatchCommitStaged(\n    environmentId: $environmentId\n    commitMessage: $message\n    skipDeploys: $skipDeploys\n  )\n}"
variables
: 
{environmentId: "f561f68e-d7ff-4aad-ab8b-3cbba0a56340", skipDeploys: false}

which doesn't appear to be documented in the apollo schema docs?

Brody•5mo ago

oh that's probably on the internal schema only for right now

Faolain•5mo ago

so then how do we create a deployment now programatically?

Brody•5mo ago

you dont want to use the internal api?

Faolain•5mo ago

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

Brody•5mo ago

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 again

well 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 plan

i 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

Faolain•5mo ago

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?

Brody•5mo ago

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?

Faolain•5mo ago

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)

Brody•5mo ago

you would want to used staged changes the same way the dashboard does it

Faolain•5mo ago

so does this require other calls

Brody•5mo ago

im not sure, you would have to look at what calls the dashboard makes

Faolain•5mo ago

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?

Brody•5mo ago

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

Faolain•5mo ago

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.

Brody•5mo ago

will do, give me a min to write an eye catching reason

Duchess•5mo ago

Thread has been flagged to Railway team by @Brody.

Brody•5mo ago

like i said, please dont wait up

Faolain•5mo ago

I will begin to list some of the issues here because this isn't quite something I can guess or reverse engineer

Ray•5mo ago

tagging in @jr to take a look!

Faolain•5mo ago

1) Previously doing

        let query = gql`
        mutation environmentCreate($input: EnvironmentCreateInput!) {
            environmentCreate(input: $input) {
                id
                name
                createdAt
                deploymentTriggers {
                    edges {
                        node {
                            id
                            environmentId
                            branch
                            projectId
                        }
                    }
                }
                serviceInstances {
                    edges {
                        node {
                            id
                            domains {
                                serviceDomains {
                                    domain
                                    id
                                }
                            }
                            serviceId
                        }
                    }
                }
            }
        }
        `
        const variables = {
            input: {
                "name": DEST_ENV_NAME,
                "projectId": PROJECT_ID,
                "sourceEnvironmentId": sourceEnvironmentId
            }
        }

        let query = gql`
        mutation environmentCreate($input: EnvironmentCreateInput!) {
            environmentCreate(input: $input) {
                id
                name
                createdAt
                deploymentTriggers {
                    edges {
                        node {
                            id
                            environmentId
                            branch
                            projectId
                        }
                    }
                }
                serviceInstances {
                    edges {
                        node {
                            id
                            domains {
                                serviceDomains {
                                    domain
                                    id
                                }
                            }
                            serviceId
                        }
                    }
                }
            }
        }
        `
        const variables = {
            input: {
                "name": DEST_ENV_NAME,
                "projectId": PROJECT_ID,
                "sourceEnvironmentId": sourceEnvironmentId
            }
        }

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?

jr•5mo ago

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?

Brody•5mo ago

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

jr•5mo ago

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

Brody•5mo ago

for their intended purposes the missing initial deploy is actually beneficial

jr•5mo ago

the changes still need to be applied to the environment. otherwise there are no services/triggers

Brody•5mo ago

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

jr•5mo ago

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.

Faolain•5mo ago

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")

jr•5mo ago

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 merged

Faolain•5mo ago

perfect 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

Faolain•5mo ago

pr-237 just deployed by me (previously was nested under staging as pr-253 is)

jr•5mo ago

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

Gaming

Programming

Create Environment no longer creating deployments