I move to GitLab and use all his tools that comes with it.
I installed GitLab v8.0.4, on my CentOs7 with Tomcat. I create a project and push a grails example to the git project.
Now I'd like to be able, every time I push a file to the project, to fire up a deploy. In jenkis I was able to pull the project, compile it with grails cmd tool, and deploy the war to the Tomcat.
I'm trying to do the same but I really feel lost. Does anybody have never try this, and can show me how to do?
If the deployment script is in the same repository as the project itself, you can have a build stage and a deploy stage. If the the build stage succeeds, it will start the deployment stage. The .gitlab-ci.yml could look like this:
stages:
- build
- deploy
build_grails:
stage: build
script:
- build-script_of_grails_cmd
deploy_to_tomcat:
stage: deploy
script:
- deploy_script_with_capistrano_or_whatever
If your deployment code is in another project you can trigger this project to start the deployment when the build stage has finished. The deployment repo should have a trigger setup. This can be done in the continuous integration menu of the deployment project. After setting up a trigger, GitLab generates a triggering curl snippet you can paste in the yml-file. The grails app gitlab-ci.yml will look like this:
stages:
- build
- deploy
build_grails:
stage: build
script:
- build-script_of_grails_cmd
trigger:
type: deploy
script:
- curl -X POST -F token=4579a6f10c51f0a4b7bdbd384f6e53 https://gitlab-comewhere.com/ci/api/v1/projects/5/refs/master/trigger
The gitlab-ci.yml in the deployment project will look like this:
stages:
- deploy
deploy_to_tomcat:
stage: deploy
script:
- deploy_script_with_capistrano_or_whatever
Related
I am rewriting my CircleCI config. Everything was put in only one job and everything was working well, but for some good reasons I want more structure.
Now I have two jobs build and test, and I want the second job to reuse the machine exactly where the build job stopped.
I will later have a third and four job.
My desire would be a line that says I want to reuse the previous machine/executor, built-in from CircleCI.
Other options are Workspaces that save data on CircleCI machine, or building and deploying my own docker that represents the machine after the build job
What is the easiest way to achieve what I want to do ?
Currently, I have basically in my yaml:
jobs:
build:
docker:
- image: cypress/base:14.16.0
steps:
- checkout
- node/install:
install-yarn: true
node-version: '16.13'
- other-long-commands
test:
# NOT GOOD: need an executor
steps:
- run:
name: 'test'
command: 'npx cypress run'
environment:
TEST_SUITE: SMOKE
workflows:
build-and-test:
jobs:
- build
- smoke:
requires:
- build
Can't be done. Workspaces is the solution instead.
My follow up would be, why do you need two jobs? Depending on your use case, pulling steps out into reusable commands might help, or even an orb.
I'm trying to set up a pipeline in Bitbucket with a daily schedule for two branches.
develop : There a scheduled daily deployment running + when I push to this branch the pipeline runs again
master : This is the tricky one. I want to have a daily deployment because the page need to be rebuild daily, but I would like to have a security that if anyone pushes to this branch by mistake or the code is bad, it only runs the deployment after a manual trigger.
So my question is that is it possible to set up a rule to track if there was a push and in this case let the admin manually start the pipeline ?
pipelines:
branches:
develop:
- step:
name: Deploy staging
deployment: staging
caches:
- node
script:
- npm run staging:auto
- npm install firebase
- npm install firebase-functions
- npm install -g firebase-tools
- firebase deploy --token=$FIREBASE_TOKEN --project $FIREBASE_PROJECT_STAGING --only functions,hosting
artifacts:
- build/**
master:
- step:
name: Deploy to production
deployment: production
caches:
- node
script:
- npm run deploy:auto
- npm install firebase
- npm install firebase-functions
- npm install -g firebase-tools
- firebase deploy --token=$FIREBASE_TOKEN_STAGING --project $FIREBASE_PROJECT_PRODUCTION --only functions,hosting
artifacts:
- build/** ```
I'd suggest to schedule a different custom pipeline other than the one that runs on pushes to the production branch. The same steps definition can be reused with a yaml anchor and you can replace the trigger in one of them.
E.g:
definitions:
# write whatever is meaningful to you,
# just avoid "caches" or "services" or
# anything bitbucket-pipelines could expect
yaml-anchors:
- &deploy-pro-step
name: Deploy production
trigger: manual
deployment: production
script:
- do your thing
pipelines:
custom:
deploy-pro-scheduled:
- step:
<<: *deploy-pro-step
trigger: automatic
branches:
release/production:
- step: *deploy-pro-step
Sorry if I make some yaml mistakes, but this should be the general idea. The branch where the scheduled custom pipeline will run is configured in the web interface when the schedule is set up.
I'm using the circleCI CLI locally to test my .circleci/config.yml. This is what it looks like:
version: 2.1
jobs:
test:
docker:
- image: circleci/node:4.8.2
steps:
- checkout
- run: echo 'test step'
workflows:
version: 2
workflow:
jobs:
- test
This fails with the following error:
* Cannot find a job named build to run in the jobs: section of your configuration file.
If you expected a workflow to run, check your config contains a top-level key called 'workflows:'
The 'hello world' workflow from the CLI docs works fine.
What am I missing here?
In the same CircleCI CLI documentation mentioned above it has in the 'limitations' section:
The CLI tool does not provide support for running workflows. By nature, workflows leverage running jobs concurrently on multiple machines allowing you to achieve faster, more complex builds. Because the CLI is only running on your machine, it can only run single jobs (which make up parts of a workflow).
So I guess running workflows with orbs works (as in the 'hello world' example), but running workflows with your own jobs does not work with the CLI.
Testing Jobs Locally
If you're looking to test your config locally like I was, you can still execute your individual jobs locally. In the same documentation linked above, under the title 'Running a Job' when using config with version 2.1+ you can explicitly call one of your jobs like so:
circleci config process .circleci/config.yml > process.yml
circleci local execute -c process.yml --job JOB_NAME
I'm trying to create a Jenkins Pipeline or group of itens to help me create a custom CI/CD for my projects and right now i'm stuck at the deploy part, i want to deploy on the same server that my jenkins is running (Windows Server/IIS). I would also like to know how to deploy to another server (Windows Server/IIS), this second one would be my production env.
I have managed to clone, build and archive using two approaches with Jenkins:
Pipelines
I have managed to create a pipeline that will clone my project, execute my build and then archive the artifacts from my build. The problem is, how do i deploy the artifact now?
This is my pipeline script
node {
stage('git clone') {
// Get some code from a GitHub repository
git 'my-git-url'
}
stage('npm install') {
bat label: 'npm install',
script: '''cd app
npm install'''
}
stage('gulp install') {
bat label: 'gulp install',
script: '''cd app
npm i gulp'''
}
stage('gulp production') {
bat label: 'gulp production',
script: '''cd app
gulp production'''
}
stage('create artifact') {
archiveArtifacts artifacts: 'app/dist/**',
onlyIfSuccessful: true
}
}
Freestyle projects
I have managed to create a project that will build and then archive the artifact using Execute shell build step and the Archive the artifacts post-build actions. How can i deploy the artifact using this approach? On this case i'm trying to trigger a second freestyle project to execute the deploy.
According to your question : "I want to deploy on the same server that my jenkins is running (Windows Server/IIS)" .. and comments I will suggest some approaches.
Windows
Use windows as operative system for production environments is not recommended. Linux is the only and the best choice.
IIS
I don't recommed IIS to deploys static assets. You need something more light and scalable. You could use :
nodejs with pm2 (https://expressjs.com/en/starter/static-files.html)
nginx (https://medium.com/#jgefroh/a-guide-to-using-nginx-for-static-websites-d96a9d034940)
apache (http://book.seaside.st/book/advanced/deployment/deployment-apache/serving-files)
docker
Deploy on IIS
Deploy static assets on IIS is just copy and paste the files on some folder and point IIS configurations to that folder:
https://www.atlantic.net/hipaa-compliant-hosting/how-to-build-static-website-iis/
Basic deploy on IIS using Jenkins
After your build commands, you just need to copy the build results (css.js.html.etc) and paste to some folder like c://webapps/my-app (pre-configured in IIS).
You can do this using a simple shell execution in free style project or pipeline script like https://stackoverflow.com/a/53159387/3957754
You could use this approach to deploy your static assets on the same server that your jenkins is running.
Advanced deploy on IIS using Jenkins
Microsoft has a tool called MSDeploy. Basically is a command line tool to deploy apps on remote IIS:
msdeploy.exe -verb:sync -source:contentPath="" -dest:contentPath=""
More details here:
https://stackoverflow.com/a/12032030/3957754
Note: You can't run MS deploy commands that talk to the MSDeploy service on the same machine
Jenkins Agent
Jenkins agent is an application that runs on a remote server, not where jenkins master node runs.
https://wiki.jenkins.io/display/JENKINS/Step+by+step+guide+to+set+up+master+and+agent+machines+on+Windows
Your master jenkins could use an agent in the remote or localhost IIS and execute jenkins jobs with copy and paste approach.
I am able to generate build trigger url and able to call build operation via Gitlab Web hook.
But the build operation is calling in each commit irrespective of any branch. But I want to trigger build operation for a specific branch commit. Means want to execute build only if any code pushed to a specific branch.
In Gitlab yaml you can specify each job to trigger on certain branches or excluding branches
https://docs.gitlab.com/ee/ci/yaml/#only-and-except
job_name:
script:
- rake spec
- coverage
stage: test
only:
- master
tags:
- ruby
- postgres
allow_failure: true
The above yaml would only execute on master