I use Jenkins to deploy a PHP webapp which uses gulp for building its assets (javascripts, styles, image optimization...).
I have a package.json and a gulpfile.js in my repo root folder which are used for development purposes, but I thought it would be a good idea to use them as well to build all my assets from my Jenkins server creating a gulp build task.
So this would be the Jenkins deployment process:
Download git repo
Run tests
Create assets from source files in repo
Do changes in code for production environment
Upload files to production server
in step 3 I have to run npm install which takes ages. Is there any way to tell Jenkins to run npm install only if package.json has changed from last commit?
Any ideas?
Related
Although it could be a silly question! but I can't find better solution so posting here.
There is existing old rails project with following detials:
Repository of on Gitlab
Using drone CI & Capistrano (already functional and doing deployments with CI)
Target server is our own server
We want to dockerize our rails app! So, Added Dockerfile and docker-compose files in project & using db from host machine. Project is working fine at local
Want to run this dockerize rails app in CI and deploy to target ENV (Staging, UAT, Production etc)?
Note: We have our own server to save docker images. Plus we don't wanna use sh scripts for the deployment.
I think using docker & drone CI, Capistrano will be removed!
So we are in the process of moving from yarn 1.x to yarn 2 (yarn 3.1.1) and I'm getting a little confused on how to configure yarn in my CI/CD config. As of right now our pipeline does the following to deploy to our kubernetes cluster:
On branch PR:
Obtain branch repo in gitlab runner
Lint
Run jest
Build with environment variables, dependencies, and devdependencies
Publish image to container registry with tag test
a. If success, allow merge to main
Kubernetes watches for updates to test and deploys a test pod to cluster
On merge to main:
Obtain main repo in gitlab runner
Lint
Run jest
Build with environment variables and dependencies
Publish image to container registry with tag latest
Kubernetes watches for updates to latest and deploys a staging pod to cluster
(NOTE: For full-blown production releases we will be using the release feature to manually deploy releases to the production server)
The issue is that we are using yarn 2 with zero installs and in the past we have been able prevent the production environment from using any dev dependencies by running yarn install --production. In yarn 2 this command is deprecated.
Is there any ideal solution to prevent dev dependencies from being installed on production? I've seen some posts mention using workspaces but that seems to be more tailored towards mono-repos where there are more than one application.
Thanks in advance for any help!
I had the same question and came to the same conclusion as you. I could not find an easy way to perform a production build on yarn 2. Yarn Workspaces comes closest but I did find the paragraph below in the documentation:
Note that this command is only very moderately useful when using zero-installs, since the cache will contain all the packages anyway - meaning that the only difference between a full install and a focused install would just be a few extra lines in the .pnp.cjs file, at the cost of introducing an extra complexity.
From: https://yarnpkg.com/cli/workspaces/focus#options-production
Does that mean that there essentially is no production install? It would be nice if that was officially addressed somewhere but this was the closest I could find.
Personally, I am using NextJS and upgraded my project to Yarn 2. The features of Yarn 2 seem to work (no node_modules folder) but I can still use yarn build from NextJS to create a production build with output in the .next folder.
I have a project in which front-end and back-end are in different tsf 2018 repositories
front-end is written on ReactJS and back-end is written on Java, i want to setup ci/cd that so when new commit is pushed into front-end repo it will create a new bundle via npm run build command and drop it into specific folder inside back-end repo.
Is it possible to do it with tsf 2018? and if so where i can find any tutorials or examples for ci/cd setup for projects with such structure
Usually you don't push the built ui into the back-end repo.
It depends on how you deploy your application but in the case of containers or image deployments, you could use tools such as jenkins or kubernetes to build a single image containing the backend with the frontend.
To make the deployment process more efficient you could split the build into 3 builds:
front-end change -> npm run build
-> mv ${FRONT_END}/build/* ${BACK_END}/public -> deploy
back-end change -> mvn install
We have created successfully a bower package and it is working great with Subversion and private-bower.
The issue I am facing now, is that we need also the generated files to be commited into (Subversion or Git) to work properly for
bower install
or
bower update
Now every build creates a conflict in the local copy of the repository.
My question is, can I tell bower to do a post install or post update command to execute a build?
In my case it should run a grunt task to build the files locally.
Just wondering if bower is not capable of doing such steps to avoid conflicts on the git/svn repository?
Or what is the suggested way to avoid merge conflicts?
There are postinstall hooks in bower https://github.com/bower/bower/blob/master/HOOKS.md but you can't rely on it as a package provider (they're designed to be used by the developpers who install your package)
For your situation, teams that provide bower packages that require a build step have two main workflows:
The repo tied to the bower registry is the source repo. Sources & build files are in it (like bootstrap). So when you bower install, you retrieve the whole repo with all the sources, build routines, etc ... which can be quite big. That's your case currently.
The repo tied to the bower registry and the repo holding the sources are two different repos (like angular):
Your build directory is in fact the repo tied to bower
Each time you make a new release, you build and then commit from that repo.
If you're having versionning problems, maybe you should switch to the second workflow (which will also let you clean all the unecessary files like build routines).
I'd like to deploy an angular+rails app on Heroku. The app is built off Emmanual Oda's example code, and compiles its assets using Grunt.
Instead of compiling my assets locally and then committing them to git, I'd prefer to compile them on Heroku. That is, I'd like to run grunt build on Heroku automatically whenever my app is deployed.
Does anyone know how I can configure Heroku to do this?
EDIT
I know server side asset compilation is possible with Node.js apps, for example using mbuchetics' fork of the heroku nodejs buildpack. When I follow the instructions at that site and push to Heroku, though, I get the following error
-----> Fetching custom git buildpack... done
! Push rejected, no Cedar-supported app detected
EDIT 2
For the time being I'm deploying using a Rake task that runs grunt build locally.
task :deploy do
system("rm -rf ./public/*") # empty the public directory
system("cd ngapp; grunt build")
# make a bogus manifest file to turn off asset compilation on heroku
# see here: https://devcenter.heroku.com/articles/rails-asset-pipeline
system("mkdir public/assets; touch public/assets/manifest-098f6bcd4621d373cade4e832627b4f6.json")
system("git add public/")
system("git commit -m \"deploying...\"")
system("git push heroku master")
end
A server side solution would be preferable!
I believe this is what you want: http://www.angularonrails.com/deploy-angular-rails-single-page-application-heroku/
This solution uses multi buildpacks to run grunt build in production. No build artifacts in version control.
My project is also based off of that sample rails app structure. May I ask why you want heroku to compile your grunt build rather than committing it? Having heroku compile it means even longer deploy times. What I do is I have a deploy script run grunt build and also run all the tests before committing to a build branch. That build branch is pushed to heroku. That way my development branch stays clean without the compiled assets in the public folder.