Modulus Deployment Error: /mnt/input/.meteor directory must exist

deployment
1

I’m trying to deploy a meteor project (doesn’t matter what’s in it, this even happens with the basic modulus test project) to modulus, and I receive the following error:

...

BUILD SUCCESSFUL

Total time: 49.54 secs
Compressing project...
31.6 MB written
Uploading project...
Upload progress [===================] 100%
Deploying project into Meteor runtime...
Starting build.
Creating directories for build environment.
Downloading source.
Executing build.
/mnt/input/.meteor directory must exist.
Build attempt failed, attempting again.
Starting build.
Creating directories for build environment.
Downloading source.
Executing build.
/mnt/input/.meteor directory must exist.
Build attempt failed, attempting again.
Starting build.
Creating directories for build environment.
Downloading source.
Executing build.
/mnt/input/.meteor directory must exist.
Build failed, reverting project.

[Error] There was a problem deploying your project.
________________________________________________________________________________
2 Likes
2

Try switching environment, from meteor to node, and update the modulus cli to the latest version.

3

I am facing the exact same issue. I am using Meteor version 1.2.1, which one are you using ?

4

I finally figured out a solution. I am using Meteor version 1.2.1 - for this you cannot use the “Meteor Runtime” option in the “Administration” panel of the project on Modulus. In order to fix this, stop your application on modulus, then select “NodeJS” in the runtime option and redeploy.

Hope it helps.

1 Like
5

I am using Meteor 1.3.2.4

6

meteor 1.3 should work fine with the ‘meteor container’ on modulus. Make sure you have the latest version of the modulus CLI (version 6 I believe) by running npm i modulus@next -g. There were a few changes to the deployment build process pushed out by the modulus guys recently, which improved the build process. You might also need to restart your application from the modulus GUI to make use of the newer build images.

Failing that, get in touch with modulus support. I have been quite impressed by the responsiveness by the support team and they have worked through a couple of issues I had that cropped up with the build process.

1 Like
7

Same here @dvmorris. Did you figure it out?

8

Yes, it should work with the latest npm package for modulus: modulus@next

9

I managed to solve this issue by using modulus@next (version 6) from my command line but run into the same problem using CI from codeship (even though I have told it to grab modulus@next and the version is right).

Has anyone else tried this type of deployment and resolved the above issue ?

10

I’m having the same problem. How can it be they have a new version of their modulus deploy tool and don’t tell their users to upgrade?

Support doesn’t work for me as I’m living in Asia, they are always asleep when I need them (12h time difference)

I’ve followed your recommendation and update modulus@next. But I’ve got this warning:

npm WARN deprecated graceful-fs@3.0.8: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.

I assume there is nothing I should do about this, it’s more for them to take actions, right?

I had to upgrade my meteor project (locally) to 1.3.2.4 and it’s finally deployed now

11

Time differences don’t matter with email. Also, you can post issues to the https://github.com/onmodulus/modulus-cli repo. It’s the same guys that respond when you get in touch with their support.

I think they do mention using newer version in the docs. That’s how I found it anyway.

12

Time difference makes a difference. It means I’m stuck my whole day with a problem, have to go to sleep and hopefully find the next morning an email with a solution. If I have a question on their answer the process starts anew. That’s a huge fu$$ing difference for me.

Compose.io is way more responsive but they do only databases unfortunately

13

That is just a warning that you are using an older version of graceful-fs and should think about updating it to v4.0. Glad you got your project deployed. That is the main thing.

1 Like
14

Is there any difference between deploying to Node.js or Meteor? I could swear a couple of months ago when I first deployed there was only Node.js available

1 Like
15

FWIW: starting from modulus-CLI version 6.0.0 (and “next”), it seems you have to use the “Meteor” runtime (from your Modulus project administration).
See also: Throw error if deploying Meteor project to Node.js runtime #117

If you stick with Node.js runtime, you have to stay with modulus-CLI 5.x, or use demetorizer and deploy that bundle.

From what I have seen, the Meteor runtime has been in beta test for a few weeks / months, and it looks like it is now offered as a standard service.

16

It’s been a while and I thought I had updated this here…

My issue on Codeship was that the ,/meteor directory is required in your GitHub repository. Once I also pushed this from my development environment, the V6 of the CLI tools worked perfectly fine. The only issue beyond that is that if you have a running instance on Modulus, and the build fails, it still reports it as successful (due to Modulus retaining the current running instance). This is both good and bad. It means your current stable instance keeps running but the build (which actually FAILS) reports SUCCESS in Codeship. I have not solved this yer (but could probably do so by checking a Version API on the app - or something similar).

17

keeping the project type as Meteor and updating my cli with, npm install -g modulus worked for me.