I have a test suite set up on a Jenkins server that I would like to be executed after an app's Docker deployment to Deis (on AWS) is complete. There doesn't appear to be any documentation around achieving this, so I'm wondering if there is anywhere in the Deis post-deployment process where I might be able to invoke a build so that I could test my app on Jenkins every time it is deployed to Deis--perhaps I could start the build with a curl command, like the following:
curl -X POST "http://jenkins.myserver.com/jenkins/job/PROJECT_NAME/buildWithParameters?APP_HOST=$host"
but I don't know where I would include this build trigger within Deis. Is there perhaps a way to include a shell script to customize actions to be taken after a deployment has finished? I've also looked for Jenkins plugins for Deis, but there appears to be none. Any advice is appreciated!
I came here looking for a Jenkins plugin for Deis too :)
Regarding your question (if still relevant to you) - IMHO this can be achieved by running the Deis deployment itself from a jenkins job - then when it's complete (and successful) - trigger another jenkins job or step for the testing.
Related
I'm developing a web application using python django. I want a CI service which can automatically pull the latest code from my github and run some test then deploy. I'm not familiar with CI, after searching for a while I found Jenkins seems to be a good solution. Can Jenkins be used for this?
Jenkins can be used with any project.
Regarding pulling the latest code, add the Jenkins GitHub plugin in order to be able to check "Build when a change is pushed to GitHub" under "Build Triggers".
That will launch your job on any new pushed commit on the GitHub repo.
From there, a Jenkins job can execute any command that you would do in command-line, provided the agent on which said job will be scheduled and executed has the necessary tools in its PATH (here python)
An alternative (which does not involved Jenkins) is to setup a webhook and a listener on your server which will detect a "push event" sent by said webhook.
Right now sorting out a good workflow using Jenkinsfiles is a bit slow since I have to create a job, and run it from the UI in order to get feedback on whether or not it works.
I was wondering if there was a way to place a breakpoint inside of a Jenkinsfile that way I could toy around and get a feel for the libraries / methods / variables that are available.
Is this something that is possible? Or do I have to stick to my current process of editing a Jenkinsfile in the Jenkins UI and then re-running the build?
--Edit--
I've found a workflow that works a little faster than making changes through the UI. The SSH server within Jenkins exposes a command called declarative-linter and one called replay-pipeline. Now I just develop the script locally and rerun these commands after I make an edit.
So basically, my workflow is like this:
Edit the script to my liking
Run the lint check. I have jenkins setup in my ssh config file, so basically I run this using Powershell:
gc Jenkinsfile | ssh jenkins declarative-linter
Run the newly changed script by replaying a pipeline build:
gc Jenkinsfile | ssh jenkins replay-pipeline <name of my job with branch name>
Run the console command to tail the logs:
ssh jenkins console <name of my job with branch name>
All I did was wrap these lines into a PowerShell function and after I edit the script locally I run one command to perform all this to validate the change. It's definitely more complicated, but the turn around time is a bit faster than it was using the Jenkins UI, plus I get to edit the script using my favorite editor. Hopefully, in the future, there will be better tooling around debugging Jenkinsfiles.
This is the only way currently. Although I know that there requests for future additions in this direction (Pipeline debugger). Probably there are some options to debug this directly from Java, but this is not a trivial setup to be done.
Add an user input
input message: "Continue?"
pipeline input step,
Read interactive input in Jenkins pipeline to a variable
I have recently started to mess about with Jenkins and am unsure how to deploy my web app to a basic server. I've gotten into the Pipeline (https://jenkins.io/doc/book/pipeline/) and it seems like a fantastic way to work.
Where I'm a bit stuck is in two spots:
Once my repo is in my workspace within Jenkins, how do I prep it so I am only deploying the files necessary for the application? For example, I don't need my src/ directory or my Vagrantfile when I'm deploying things.
How do I deploy my app to the server? I see examples all over the place, but I am getting a bit lost since there seems to be so many ways to do this. I'm assuming scp or something like that...?
To build off of #2, is there a way to deploy web apps as transactions (in one shot) rather than file-by-file?
Please let me know if I can provide any information for potential answers!
I can't speak to your specific use case but a common way to do this is the build-and-deploy model, where you will have 2 Jenkins jobs. The "build" job will check out from source, run build commands such as maven or make, and lastly will "archive" the build artifacts. The latter is an option under the 'post-build actions' tab at the bottom.
In the "deploy" job, you will grab the artifacts of your choice. You can fetch a single file, all of them, and everything in between. This requires use of the 'Copy Artifact' plug-in and it allows you to copy files generated by other jobs. Now you can run your usual deploy script in the 'Execute Command' box. Most command line paradigms are supported out of the box such as setting environment variables.
The instructions above assume that you want to run your application off of a host that you've provisioned as a Jenkins slave.
Use artifacts as mentioned by Paul Back, or a 3rd party artifactory server as in video
This is always tricky and error-prone. Why not spin up a fresh server with new release (humanly verified once)
Jenkins & Ansible is the answer here. This is how I deploy to production, since I am in no need to use anything like Docker (too many issues with particular app) so have to run the app natively. Quick example would be
You monitor a specific branch in gitlab / github or whatever else and then call a webhook on push / merge etc on that branch, at this point you deal with anything you need to do by running a playbook on the jenkins job that monitors that branch (jenkins).
in my case jenkins and ansible run on the same server. Jenkins runs the ansible playbook that does whatever I need to do.
for example with ansible, I copy certain files that need to be there, run configs / change filenames etc. setup nginx, run composer,
you get the point.
We are searching for a CI and CD Solution for our WebApp based on NodeJS/Meteor.
Our Process should be:
On each Push to Master/ Pull Request/ Merge to Master do the following:
Checkout
Run Code Style Checks (coffeelint, scsslinter, etc.)
Build Code
Run Tests
Generate Tarball-Archive
Deploy archive to Developmet (Quality Management) Server, extract and run
next step would be manual testing of the app on our dev server.
when we think it is deployable, I want have a button in jenkins like "Deploy these Artifacts NOW to Live-Instance". How can I achive this? Also Nice would be something like deploy these artifacts at 2am to the live instances.
From Checkout to deploy to dev-server is already implemented in jenkins. What we need now is a button "deploy this artifact to live"
You need another job to get this working. The other job takes the artifact from the build job and deploy it wherever you want.
There is no possibility to include such behavior in the same job.
I am looking for implementation of CI/CD in to my current project here is what i think will work.
Environment consists of
- Jenkins
- git
- docker
- gradle
- Linux servers
- Sonar
- Ansible.
Each tool will be used as following.
Git:- Developers will push there code to this CVS.
Jenkins:- On detecting Check-in Jenkins will trigger a build and will deploy to one of the server.
Sonar:- will be used for code coverage and will check the code before building the same through Jenkins.
ansible:- ansible will be used to quickly prepare added nodes so that code can be deployed to them.
Docker in case if we need fresh test environments every time we can use docker+ ansible combo for doing the things.
Flow of work will be
User run unit test cases on his machine and commits the code to the server.
Jenkins will pull the code from git and will run sonar on the same and will generate reports.
jenkins will create build and will deploy the same on dev server.
A jenkins job will run and will perform the integration testing on the dev server
Any other automated tests can be run.
Finally builds pushed to next server using Jenkins.
I will use shell commands inside Jenkins to push compiled code from one server to another.
In my this scenario can some one answer me following.
Where will sonar get fit and how to use the same?
I see there are CD tools, cant i push compiled code to the servers using shell scripts written inside the Jenkins jobs to automatically deploy the things? What extra benefits a CD tool provides
Is is wise to create fresh test environment or we can keep using the old one again and again?
Will this complete CI/CD?
can someone share there implementation
You say you plan to use Git. I'll outline a scenario using Git on GitHub
Developers push code changes here as pull requests
The SonarQube GitHub Plugin kicks off an initial analysis of only the code changed in the PR looking for the introduction of new issues (note that coverage and duplications are not included in this check)
Once the PR is merged, Jenkins (in one job or several, depending on your needs)
builds
fires integration tests & any other automated tests
runs SonarQube Scan. Note that this comes last to include integration test results.
pushes build to next server
Note that the ability to break the build when the project doesn't pass the SonarQube Quality Gate you've set up may be desirable in your situation. Unfortunately, it's not available in the current server version: 5.2. It is available in 5.1, and is should return soon.