Realm app auto deployment - not deploying Rules, Schema (but is deploying Functions, Triggers, etc.)

Hi Mongo Community,

Frequent reader (as of late) - first time poster.
I’ve configured the GitHub auto-deployment to deploy our Realm app from our DEV env to our “next,” env - QA. I’ve gone through the tutorials, and our company has had a recent “accelerated” consulting engagement - and this was all POC’d and working fine with two personal/free-tier Projects & Realm-apps (exporting with realm-cli beta 4).

However, what I see now is that “mechanically” the auto-deployments are working (evident by the History tab) - but it seems that ONLY the Functions, Triggers, Values & Auth Provider of the app are deploying (and NOT the Schema, Rules, and GraphQL Schema/Customer Resolvers) - even though I clearly see all the json files under the data_sources/mongodb-atlas sub-structure (with the db and collections).

Other notes:

  1. current realm-cli is 2.0.0.-beta.5
  2. the realm_config.json only has the realm app name and config version fields (all other fields removed), and the data_sources/mongodb-atlas/config.json has had its config.clusterName field removed - see screenshots below.


So with that - is there something that I’m fundamentally missing? I’m happy to provide any other info that might help.

Thanks in advance!


1 Like

Hi @Christopher_Roth.

I wanted to check a couple of things.

Was the app exported in the new format, if you’re not sure then it would be good to export it again?

What happens if you try to manually import the app using realm-cli?

Hi @Andrew_Morgan,
Thank you for the prompt follow-up - very much appreciated.
There’s nothing too propriety/sensitive about the info in the exported realm-app structure - nonetheless, if it’s OK, I’m going to attempt to email that do you directly. It’s a text file w/ the result of the Windows cmd “tree” commend (more’ing it in a command prompt allows it to display pretty).
And then I’ll have to follow-up later in the day today with the result of importing the app directly into our QA env via realm-cli - and I appreciate the suggestion.

Hi! I have the same problem. And yes it works with realm-cli, schema imported properly. But if use automatic deploy again it resets back and deletes all schemas.

Ah, interesting (but sorry to hear Mikhail). I appreciate you sharing your experience; I expect to confirm the same later today (I have a number of other priorities to work on this morning).

Hi @Andrew_Morgan,
Just a quick follow-up that I got back to it, and can confirm (Mikhail’s observation) that when importing the Realm app via the realm-cli, the entire configuration imports successfully (the Schema & Rules look good - and all other artifacts).

This looks like a similar issue I was having with deploying the Realm App via GitHub. Everything except the schema rules and webhooks imported. I’m guessing you don’t use webhooks and therefore don’t see that they are not there either. Realm app export and import via GitHub fails

@Christopher_Roth I liked your screenshots and description of the problem. Much better than mine!

@ConstantSphere - thanks for contributing! In fact, I did read you post - but wasn’t quite sure if it was the same issue, and so submitted this post. But, it does seem that we encountered the same GitHub auto-deploy issue; and perhaps I was hasty, but I didn’t notice (or couldn’t see) any realm app structural difference, compared to when this was working for me (granted, in the context of different projects/clusters) just a few weeks ago - at least not beneath data_sources/mongodb-atlas/(db name)/… directories. And you’re correct, our app does not (yet?) have any web hooks.

Hi - just thought I’d post a follow-up. @Andrew_Morgan - assuming you received the tree-view .txt file of my exported realm app structure, is it OK / what you expected? Should I fall back to an earlier realm-cli version (to beta 4 if that’s possible)? Any other action that I can/should take? Thanks in advance!

Hi @Christopher_Roth, sorry - I got distracted by other activities!

I just created a new app, exported it, added it to GitHub, and then linked it to a new app.

The only change I had to make to make it work was to change name in /realm_config.json.

I no longer need to remove config.clustername from /data_sources/mongodb-atlas/config.json - looks like that’s been fixed.

I checked the directory structure for data_sources and mine seems to match yours.

Does the linked data source have the same name (mongodb-atlas) in the app you’re trying to import into?

Hi @Andrew_Morgan - thanks and no worries. I appreciate the update & will take another crack at it here this afternoon (and be prepared to do a realm-cli import, if it doesn’t appear to work). And yes, our target env’s realm-app has the same linked source name of mongodb-atlas - image

Thanks and I’ll follow-up with what I see. Regards!

Hi @Andrew_Morgan - apologies, it wasn’t until today that I was able to get back to this. I still see the same results - and that being that the Rules & Schema content are deleted upon a “successful” auto-deployment via GitHub.
I’d un-installed and re-installed the realm-cli (now beta 6); being on windows, I toggled the git core.autocrlf configuration setting (to ensure that only LF chars remain in the files upon commit into GitHub) - but all resulted in the same.
So, I re-imported the app into our QA env via the realm-cli import command (which works) to ensure the app’s successful deployment in that env, but I’m back to being at a loss as to what else to try.
Is there a new GitHub Mongo app that I should re-install in GitHub?
I think perhaps I should re-engage the Mongo engineer that conducted our accelerated consultation - again, at that time (April 22/23) - this all worked.

Hi @Christopher_Roth. We noticed recently that a deployment to our production system (using the “old directory structure”) appeared to work, but it was actually enforcing the previous schema rules. Checking the UI showed the new schema rules were in place but it wasn’t until we added a single space to the file via the UI and deployed via the UI that it actually took effect. Have you seen any behaviour like that on your system?

1 Like

Hi @ConstantSphere, thanks for following-up & I think I follow - and no, I don’t believe I’ve yet to see this (but will keep an eye out for this scenario as we make subsequent deployments). That said, we’re early in our project’s life, only have have two envs so far (Dev and QA), and haven’t performed many deployments (our project’s had a bit of swirl recently, not Mongo-related). But, we’ll be getting back to deploying up to QA (and higher) from Dev here on a regular cadence shortly.

I think our situation is that a) our project has only ever been on the “new Realm directory structure,” and b) I went ahead and opened a Mongo Support ticket (for this topic) last week, and demo’d the behavior to two Mongo support engineers late last week. And from that session, I think I we identified our issue - and that is, in our GitHub repo… the Realm app content (its full directory structure) was checked into a sub-directory within the repo (and not into its “root”), and even though the Realm deployment config specified that sub-directory (to deploy from), well - that was the issue. I created a second/new GitHub repo (with no sub-directory for the Realm app, and not other content), and just committed the Realm app into it (at the root) - making the typically realm_config.json and data sources config.json updates - and when merging from one branch to another, it all deploys fine to the target/QA env (incl. the Rules & Schema).
So now I’m just waiting for one of the Mongo support engineers to replicate my scenario (given a GitHub repo with a sub-directory that contains the Realm app content), and confirm whether he sees the same / what we all observed when working together.
I’ll update this post once that’s been confirmed (or refuted).

I have seen this exact same behavior, and discovered the same workaround. It has me rather concerned, what if an update to production doesn’t get applied?

I just tried to make a repro for this issue with a new project, but wasn’t able to reproduce the behavior with a new application. I can consistently reproduce this in an existing application though, I will file a support ticket when I have a window where I can leave my dev environment in a bad state for support to examine.