Unable to build installer on travis with --build-meteor flag

[Coygo]

TLDR: Able to build on travis when I spin up a Meteor server, wait 3-4 minutes and pull the index.html and then package. Unable to build on travis when I use the --build-meteor. Both ways work locally.

meteor version: 1.6.1.4 meteor-desktop version: 1.6.0 node: 8

package.json

scripts: {
   "start:desktop": "meteor-desktop"
}

When I run the following locally, it packages the installer correctly:

meteor npm run start:desktop -- build-installer --build-meteor --mac --production --meteor-settings config/config.prod.json

or

meteor npm run desktop -- build-installer --build-meteor --win --linux --production --meteor-settings config/config.prod.json

When I run the following commands on travis I get similar output like this:

DEBUG  meteorApp:  meteor version is >= 1.3.4.2 so the index.html will be downloaded from __cordova/index.html
INFO  meteorApp:  building meteor app
INFO  meteorApp:  running "meteor run --verbose --mobile-server=http://127.0.0.1:3000 --production -p 3080 --settings config/config.prod.json"... this might take a while

then it all explodes with:

=> Started MongoDB.WARN  meteorApp:  STDERR: x akryum_vue-component-dev-client-0.4.2/
WARN  meteorApp:  STDERR: 
x akryum_vue-component-dev-client-0.4.2/isopack.json
WARN meteorApp: STDERR <insert every single package>

Has anyone successfully used travis and the --build-meteor.? Is there some connectivity issue I am doing incorrectly?

The interesting part is I was able to "hack around" travis and spin up the Meteor server, wait for it to be ready, then pull down the index.html and build the app successfully. I am just trying to use the build-meteor setting because that takes a long time and this would be an improved way.

[wojtkowiak]

Hey, whenever sth is being printed to STDERR when running meteor the build process will stop just to prevent using a faulty build. You can see from the logs that this: STDERR: x akryum_vue-component-dev-client-0.4.2/ is being printed to stderr. Can you check if running the same command manually on the terminal meteor run --verbose --mobile-server=http://127.0.0.1:3000 --production -p 3080 --settings config/config.prod.json also produces those? It would be good to understand why they appear on stderr and if possible get rid of them. As a last resort you can use the -i switch to ignore certain strings. I did not test it but in theory you can bypass this mechanism at all by using -i " " as it should ignore every stderr line containing space.

[Coygo]

I have upgraded meteor-desktop to the latest and meteor to 1.7.0.5 and I get different errors now:

Note: this is running inside the docker container:

    meteor npm i --production;
  - |
    if [ "$TRAVIS_OS_NAME" == "linux" ]; then
      ENVS=`env | grep -iE '^(DEBUG|NODE_|ELECTRON_|METEOR_|YARN_|NPM_|CI|CIRCLE|TRAVIS|APPVEYOR_|CSC_|_TOKEN|_KEY|AWS_|STRIP|BUILD_|GH_|PUBLISH_)([A-Z]|_)*=' | sed -n '/^[^\t]/s/=.*//p' | sed '/^$/d' | sed 's/^/-e /g' | tr '\n' ' '`
      docker run --network host $ENVS --rm \
        -v ${PWD}:/project \
        -v ~/.cache/electron:/root/.cache/electron \
        -v ~/.cache/electron-builder:/root/.cache/electron-builder \
        -v ~/.meteor:/root/.meteor \
        electronuserland/builder:wine-chrome \
        /bin/bash -c "export PATH='/root/.meteor:$PATH' && <meteor code here>"
    fi

When I run:

meteor npm run desktop -- build-installer 127.0.0.1:3000 --build-meteor --production -p 3080 --meteor-settings config/config.prod.json

It seems to get past the In remote catalog refresh Returning sync token: but now it never makes it to the [[[[[ /project ]]]]] => Started proxy.

I get:

DEBUG  meteorApp:  meteor version is >= 1.3.4.2 so the index.html will be downloaded from __cordova/index.html
INFO  meteorApp:  building meteor app
INFO  meteorApp:  running "meteor run --verbose --mobile-server=127.0.0.1:3000 --production -p 3080 --settings config/config.prod.json"... this might take a while
INFO  meteorApp:  building in progress...
ecmascript-runtime-server-0.7.1/npm/node_modules/core-js/library/fn/object/get-own-property-names.jswrite /dev/stdout: resource temporarily unavailable

When I run:

meteor run --verbose --mobile-server=127.0.0.1:3000 --production -p 3080 --settings config/config.prod.json

I get the whole thing running:

Local package version is up-to-date: [email protected]
Local package version is up-to-date: [email protected]
...
Finished extracting in 732 ms
akryum_vue-component-dev-client-0.4.2/

[Coygo]

It seems like moving meteor npm i --production within the docker container made the -b get further (but now runs the system to the max log length. Can I turn off the --verbose mode with -b. If not, I can hack around it by using -a stderr on the docker run but not my preferred option)? Also, don't know why the meteor runs works without npm i --production being inside the docker container but I won't worry about that.

[wojtkowiak]

Ok, so you are using a container to build your app, right? So it seems that it is downloading meteor packages during build. Seems that the logs from unzipping the packages is clogging docker's stdout. So indeed resigning from --verbose should help. I will take a look at it.

Also, don't know why the meteor runs works without npm i --production

No sure how this is related to the problem. TBH I have no idea what that has to do with it. Do you have meteor-desktop in dependencies? I mean it should be in 'devDependencies. Running npm i --productionnormally would removemeteor-desktop`.

[Coygo]

Ok, so you are using a container to build your app, right?

Yes. Referenced from here: https://www.electron.build/multi-platform-build#sample-travisyml-to-build-electron-app-for-macos-linux-and-windows

So indeed resigning from --verbose should help. I will take a look at it.

Awesome. For now, I am just passing in the -a stderr and trusting that it completes. Not ideal, but a workaround for now.

Do you have meteor-desktop in dependencies?

Yes. It has always been in dependencies. I assumed its similar to electron/electron-builder that has to be in dependencies. If it is in devDependencies, will the same functionality work? If we do a meteor npm i w/o --production, we are going to potentially bundle all our dev apps as well (which would be bad and bulky). Am I missing something?

[Coygo]

I spoke too soon. I got it working in container (for windows and linux) as mentioned above, but I run into the STDERR for the mac os builds on travis.

Same situation as above:

Running meteor npm i --production && meteor run --verbose --mobile-server=127.0.0.1:3000 --production -p 3080 --settings config/config.prod.json;

outputs

Local package version is up-to-date: [email protected]
Local package version is up-to-date: [email protected]
...
Finished extracting in 732 ms
akryum_vue-component-dev-client-0.4.2/

running

meteor npm run desktop -- build-installer 127.0.0.1:3000 --build-meteor --production -p 3080 --meteor-settings config/config.prod.json

produces the

=> Started MongoDB.WARN  meteorApp:  STDERR: x akryum_vue-component-dev-client-0.4.2/
WARN  meteorApp:  STDERR: 
x akryum_vue-component-dev-client-0.4.2/isopack.json
WARN meteorApp: STDERR <insert every single package>

when using -i ' ' it still doesn't catch everything:

WARN  meteorApp:  STDERR: fp/subtract.js
WARN  meteorApp:  STDERR: 
WARN  meteorApp:  STDERR: fp/toArray.js
WARN  meteorApp:  STDERR: flow-strip-types/README.md
WARN  meteorApp:  STDERR: 
WARN  meteorApp:  STDERR: flow-strip-types/lib/