NPM not available when running installation script - npm

I have an interesting issue, I have a setup or rails project and the deployment/upgrades works absolutely fine when running as a dedicated user (deploy) who is used to setup everything.
I am using codeDeploy to manage the deployments and it uses root user to do the deployment on AWS, but during the deployment it fails on running the same script because it's not able to find npm command
cd client && npm run build:client
sh: 1: npm: not found
rake aborted!
Command failed with status (127): [cd client && npm run build:client...]
If i run it manually to check that i also get nothing
root#ip-172-31-4-141:/home/ubuntu# su deploy -c "which npm"
root#ip-172-31-4-141:/home/ubuntu#
NPM is available via the deploy user but I am struggling to understand why it's not available via the root user
deploy#ip-172-31-4-141:/home/ubuntu$ which npm
/home/deploy/.nvm/versions/node/v7.8.0/bin/npm
Any help to get this resolved would be great.
Thanks,

The issue here was that AWS CodeDeploy when starts deployment loads only a minimum env; to load all the env variables I have exported the env and then in the deploy phase source that file, which resolves my issue

Related

Self-hosted GitLab Runner with shell executor can’t find npm

I’m configuring a very simple CI job. GitLab Runner is running on my own server, the specific runner for this project has been registered, with the shell executor, as I want to simply run shell commands.
stages:
- build
build:
stage: build
script:
- npm install
- npm run build
artifacts:
paths:
- "public/dist/main.js"
only:
- master
The job fails at the first command, npm install, with npm: command not found. I just installed npm and node via npm. If I SSH on my server and run npm -v, I can see version 8.5.5 is installed. If I sudo su gitlab-runner, which I suppose is what GitLab Runner is running as, npm -v works just as well.
I installed npm while gitlab-runner was already running. So I ran service gitlab-runner restart, thinking that it had to reevaluate its PATH, but it didn’t fix the issue.
I fixed it by simply adding this command before npm install: . ~/.bashrc.
I’m not sure why gitlab-runner didn’t properly read .bashrc before, even though I restarted it. Maybe it’s not supposed to? That would be contrary to what’s said in the GitLab CI runners docs.
N.B.: A key element in me being able to debug this was to clone the repo on a folder on my server, cd into it, and run gitlab-runner exec shell build after any (local) change to .gitlab-ci.yml. Skipping the whole commit + push + wait was a huge time (and sanity) saver.

AppCenter Yarn 1.19 error Incorrect integrity when fetching from the cache

I have a React Native app hosted on Microsoft App center. The builds (both iOS and android) are failing because of yarn 1.19 (error Incorrect integrity when fetching from the cache)
I tried to remove the package-lock.json but it didn't help.
I would like to downgrade yarn or execute the cache clean command but don't know where to execute it.
I have installed the appcenter cli version 2.2.1 and successfully connected to it.
Where could I execute yarn cache clean for example?
I've read I could also create a script but I have no idea where to place it and how it should look like. Should it be both in the ios and android directory? Or in the root? Thank you
I actually noticed that I had a yarn.lock back from the initial commit, even though we are using npm in the team.
In the build logs, there is this line:
/bin/sh -c if [ -f yarn.lock ]; then { yarn install && yarn list --depth=0; } else npm install; fi
So I deleted the yarn.lock file and now it builds successfully using npm!
Not sure whether you build your React app with Azure Devops pipeline. If yes, you can use Command line task to achieve the things you want to do.
If the agent you used is hosted agent during the build, since each build will use a completely new VM, you need to install the AppCenter cli once per build.
Use follow command to install the AppCenter cli:
sudo npm install -g appcenter-cli
Then logging in it:
appcenter login --token {Token}
Here, you need first generate the token with this doc described: Go and login to https://appcenter.ms/ -> Click Self Avatar -> Choose Account Settings -> Click on API Tokens -> Click New API token then select the corresponding the scope for this token.
Copy and use it in this pipeline task. Note: Recommend you store
this token with secret variable for security.
Now, you can execute the clean command: yarn cache clean.
Where to place it and how it should look like?
According to your description, you need place this command line task into the first step, then it could clean the Yarn cache firstly.
Also, because of the image configuration that the hosted agent is using, its installed node.js version is 6.7.0, this does not match the runtime environment for AppCenter cli. You need also run Node.js tool installer task to install node.js v10.0.0.
All of them should look like this:
Should it be both in the ios and android directory?
As I mentioned previously, for Hosted agent, each build will use a completely new VM. So yes, you must execute these two steps firstly in every build.
If what you used is your private agent, since you have installed the AppCenter cli locally, the agent will automatically call the local configuration when running the command line task. At this time, you just need to skip the install command in the command task:
We fixed it by adding a "yarn cache clean" in appcenter-post-clone.sh, you can add this shell script in root of project.
See this docs for details.

Errors when Pushing Vue.js app with IBM Cloud+Cloud Foundry Node Buildpack

I am really new (this is my first time) to using IBM Cloud.I have a Vue.js app that I would like to deploy on IBM Cloud with continuous delivery. I have my Vue project in a GitHub repository, and I would like to be able to deploy the project automatically upon changes to the master branch of the repository. I have successfully set up the tool chain so that the "Delivery Pipeline" runs upon changes to the master branch. See screenshot:
Within the Delivery Pipeline, I have two stages: Build and Deploy. See screenshot 2:
I (think) I have successfully set up the Build Stage, where I install npm, then proceed to run the command "npm run build" to create a deployable bundle, with this script:
bash
#!/bin/bash
export NODE_VERSION=8
export NVM_VERSION=0.33.11
npm config delete prefix \
&& curl -o-
https://raw.githubusercontent.com/creationix/nvm/v${NVM_VERSION}
/install.sh | bash \
&& export NVM_DIR="$HOME/.nvm" \
&& . $NVM_DIR/nvm.sh \
&& nvm install $NODE_VERSION \
&& nvm alias default $NODE_VERSION \
&& nvm use default \
&& node -v \
&& npm -v
echo "Installing NPM"
npm install
echo "NPM install successful"
echo "Attempting npm run build"
npm run build
echo "NPM run build successful"
This is where the uncertainty arises. I want to deploy the project, which after npm run build should just require index.hmtl and build.js, which is in the 'dist' folder.
I don't know if this is necessary, but following the npm install and npm run build stage, I added this stage, which I really don't know what does. I have only added it because the boilerplate SDK for Node.js™
had this stage prior to the deploy stage, see screenshot 3:
After this, I have the Deploy stage set to take the 'Simple Build' stage as its input. It deploys it with a simple cloud foundry push command. However, I get these errors in the log, after it downloads the various buildpacks:
Staging...
-----> IBM SDK for Node.js Buildpack v3.25.1-20190115-1637
Based on Cloud Foundry Node.js Buildpack v1.5.24
-----> Creating runtime environment
NPM_CONFIG_LOGLEVEL=error
NPM_CONFIG_PRODUCTION=true
NODE_ENV=production
NODE_MODULES_CACHE=true
-----> Installing binaries
engines.node (package.json): unspecified
engines.npm (package.json): unspecified (use default)
Resolving node version (latest stable) via 'node-version-resolver'
Installing Node.js (6.16.0) from cache
Using default npm version: 3.10.10
-----> Restoring cache
Loading 2 from cacheDirectories (default):
- node_modules
- bower_components (not cached - skipping)
-----> Building dependencies
Installing node modules (package.json)
-----> Installing App Management
WARN: App Management cannot be installed because the start script cannot be found.
To install App Management utilities, specify your 'node' start script in 'package.json' or 'Procfile'.
Checking for Dynatrace credentials
No Dynatrace Service Found (service with substring dynatrace not found in VCAP_SERVICES)
-----> Caching build
Clearing previous node cache
Saving 2 cacheDirectories (default):
- node_modules
- bower_components (nothing to cache)
-----> Build succeeded!
└── vue#2.6.10
! This app may not specify any way to start a node process
http://docs.cloudfoundry.org/buildpacks/node
Exit status 0
Staging complete
Uploading droplet, build artifacts cache...
Uploading build artifacts cache...
Uploading droplet...
Uploaded build artifacts cache (15.3M)
Uploaded droplet (29.4M)
Uploading complete
Stopping instance 64ed3f5f-71eb-477b-afc1-0e07e2e74fdb
Destroying container
Successfully destroyed container
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 crashed
FAILED
Error restarting application: Start unsuccessful
Any ideas? Where am I going wrong? Any help would be greatly appreciated!
Got it working. I just needed to add the dependencies/require statements in the app.js file (some Express stuff), and then I removed that extra 'Simple build" stage

npm install when deploy Octopus

I need to create node_modules in the root app when deploy new version using Octopus
How can I create a run script using a new octopus step? I try:
npm install
But I get error when execute the script step
'The remote script failed with exit code 1'
Any ideas?
Your build system should be handling that for you. The node_modules directory should then be included in your application package, but ideally, this should also be bundled to reduce the number of files that your application is dependant on.
If you do need to run this as part of a deployment, then you would need NodeJS and npm installed on the server that is executing the deployment step (either the Octopus server itself or a worker instance if using workers).
For more information check out this blog post

Deploying Laravel 4 with Capistrano. Permission denied during `composer install`

I'm trying to use Capistrano to deploy my Laravel 4 site and when I try to:
run "cd #{current_path} && composer install --no-dev"`
in my deploy.rb I get this error:
sh: 1: composer: Permission denied
and a few lines later:
failed: "sh -c 'cd /var/www/public/mysite/current && composer install --no-dev'" on root#my.ip.add.ress
If I comment out the run command above then Capistrano is able to complete the deployment successfully. However, I then have to manually run composer install from the current release directory of my site in order to get everything on my site working properly.
I've tried running my deploy with the -d flag to go through the deployment step by step, I've tried fixing permissions in case they were incorrect, but neither seems to fix this error. Also, I've looked all over for a possible answer and can't find anyone else with this specific issue.
So, I have two questions:
Any ideas of a fix to this?
It seems like running composer install each time I deploy is just creating more work than is necessary. Would it be better to either:
a) not ignore the vendor folderin my local repository therefore removing the need to runcomposer install` on each deploy? Or,
b) run composer install in the root directory (at the same directory level as current and releases) and then change the path to vendor/autoload.php in the bootstrap directory to point to this new directory so I never need to run composer install again?
I figured it out. Instead of:
run "cd #{current_path} && composer install --no-dev"
I'm doing this instead:
run "cd #{releases_path}/#{release_name} && php /usr/local/bin/composer/composer.phar install --no-dev"
(I changed #{current_path} to #{releases_path}/#{release_name} because Capistrano was executing rm -f /var/www/public/myapp/current AFTER the composer install command.