I'm getting started with Laravel and Jenkins. First time using either of these technologies. I have Laravel installed and got the welcome page showing. I now want to install Jenkins. I was looking at this tutorial but that installs Laravel differently. I've used composer to install Laravel so I'm not entirely sure how I should do the "configure the build" step:
Configure build
Now clone my github repository laravel-jenkins which is the boilerplate for all the config files and the Jenkins job.
cd /var/www
git clone git://github.com/modess/laravel-jenkins.git
mv laravel-jenkins/* laravel/
cd /var/www/laravel
Now you should have these files in your Laravel directory as well:
build/
- code-browser/
- coverage/
- logs/
- pdepend/
- phpcs.xml (PHP Code Sniffer config)
- phpmd.xml (PHP Mess Detector config)
build.xml (build config)
config.xml (Jenkins job config)
phpunit-bootstrap.php (PHPUnit bootstrap script)
phpunit.xml.dist (PHPUnit config)
Can anyone offer any suggestions on how best I proceed with this?
There is no issue that you installed Laravel via Composer opposed to the git clone recommended in the article (your approach is actually the recommended approach according to Laravel Docs).
To answer your primary question the instructions are having you git clone the authors public Github repo which provides files that will be moved over into your laravel project (they are unique files so nothing from Laravel will be overwritten). Here is a breakdown:
For Reference: I am assuming you followed his example and your Laravel project will is located in /var/www/laravel.
"cd /var/www" - This will bring you to the parent folder of your Laravel project (there should only be laravel/ and an index file of some sort in this folder)
"git clone git://github.com/modess/laravel-jenkins.git" - This will pull all the files from the authors public git repo, if you feel more comfortable you can download as ZIP directly from Github and upload via SFTP or FTP (or just use wget). These files will be located in a newly created folder located at /var/www/laravel-jenkins
"mv laravel-jenkins/* laravel/" - This command just moves all files and folders from /var/www/laravel-jenkins/ to /var/www/laravel (if the files being moved already exist in /var/www/laravel they will be overwritten)
That is all that is needed to be done to have the authors "Jenkins/Laravel Boilerplate" active on your Laravel install.
IMPORTANT NOTE: You said you were using Laravel 5 and the authors instructions are specifically for Laravel 4, there is a very high possibility that this tutorial will not work in a Laravel 5 project as the file structures between Laravel 4 and 5 have many differences.
Related
I have some common configurations files that are the same for many projets. It's very painful to manage because they are just duplicate and when I have a modification for one file I need to do it for all of them.
I want to find a solution with gitlab ci/cd to share common configuration files across different projects.
I saw in the Gitlab documentation that you can include other gitlab files here / cd here. But I don't want to share only the yaml configuration file, I want to share all the configuration files that are the same in my projects.
I found an idea but I don't know if it's a good one.
Imagine a project named "A" and a project named "Common Configurations Files".
The "Common Configurations Files" project will contain all the common configurations files in a "config" folder and a gitlab ci/cd file with a function that can copy the files to the root folder.
Project A will include files and will call the before_script step to copy the files to the root folder.
I don't know if it can work and I don't know how to do it.
I saw two other options but I don't know if it's suitable:
Gitlab artifact
git submodule
Both options, either working with a submodule or artifacts, should work for your case. Using submodules would add a little bit more complexity as you would need to keep the submodules updated in all your dependent repositories.
Another option that would be suitable here would be the use of Gitlab Generic Packages. If you have a Repository that includes all your configuration files, I would suggest creating a pipeline for this repository which versions/tags the repo upon changes. After versioning, I would zip the content up and push it to this projects package repository.
curl --header "PRIVATE-TOKEN: <your_access_token>" \
--upload-file path/to/file.txt \
"https://gitlab.example.com/api/v4/projects/24/packages/generic/my_package/0.0.1/dependencies.zip"
In all your dependent projects, in the before_script you could just download and extract the zip file.
curl --header "PRIVATE-TOKEN: <your_access_token>" \
"https://gitlab.example.com/api/v4/projects/24/packages/generic/my_package/0.0.1/dependencies.zip"
The example in the docs looks like this and might help you get started.
image: curlimages/curl:latest
stages:
- upload
- download
upload:
stage: upload
script:
- 'curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file path/to/file.txt "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/my_package/0.0.1/file.txt"'
download:
stage: download
script:
- 'wget --header="JOB-TOKEN: $CI_JOB_TOKEN" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/my_package/0.0.1/file.txt'
I have made a ROS workspace and inside a package.
I did catkin_make and everything is working well.
I would like to give this package (or should I give the entire workspace?) to another person.
I am thinking to give him a zip file of the files and folders (it contains launch files, python scripts, rviz files etc) so I am expecting he will unzip it in his machine
I would like he can run the launch files without problems
What is what he needs to do for this? (of course he will have ROS installed, that is no problem)
I am thinking perhaps he should do source devel/setup.bash but is this enough?
When sharing a workspace with somebody only the source space src has to be shared. It should contain all our packages with their launch files (*.launch), Python (*.py) and C++ nodes (*.cpp, *.hpp), YAML configuration files (*.yaml), RViz configurations (*.rviz), robot descriptions (*.urdf, *.xacro) and describe how each node should be compiled in a CMakeLists.txt. Additionally you are supposed to keep track of all the Debian packages you install inside the package.xml file of each package.
If for some obscure reason there are things that I have to do that can't be accommodated in the standard installation instructions given above, I will actually write a bash script that performs these steps for me and add it either to the package itself or the workspace. This way I can automate also more complex steps such as installing OpenCV or modifying the .bashrc. Here a small example of what such a minimal script (I generally name them install_dependencies.sh) might look like:
#!/bin/bash
# Get current workspace
WS_DIR="$(dirname "$(dirname "$(readlink -fm "$0")")")"
# Check if script is run as root '$ sudo ...'
if ["$EUID" -ne 0]
then
echo "Error: This script has to be run as root '$ sudo ./install_dependencies.sh'
exit 1
fi
echo "Installing dependencies..."
# Modify .bashrc
echo "- Modifying '~/.bashrc'..."
echo "source ${WS_DIR}/devel/setup.bash" >> ~/.bashrc
echo ""
echo "Dependencies installed."
If for some reason even that is not possible I make always sure to document it properly either in a Markdown *.md read-me either in a /doc folder inside your package, in the read-me.md inside the base folder of your repository or inside the root folder of your workspace.
The receiver then only has to
Create a new workspace
Copy or clone the package files to its src folder
Install all the Debian package dependencies listed in the package.xml files with $ rosdep install
(If any: Execute the bash scripts I created by hand $ sudo ./install_dependencies.sh or perform the steps given in the documentation)
Build the workspace with $ catkin_make or $ catkin build from catkin-tools
Source the current environment variables with $ source devel/setup.bash
Make sure that the Python nodes are executable either by $ chmod +x <filename> or right-clicking the corresponding Python nodes (located in src or scripts of your package), selecting Properties/Permissions and enabling Allow executing file as program.
Run the desired Python or C++ nodes ($ rosrun <package_name> <executable_name>) and launch files ($ roslaunch <package_name> <launch_file_name>)
It is up to you to share the code as a compressed file, in form of a Git repository or a more advanced way (see below) but I will introduce some best practices in the following paragraphs that will pay off in the long run with larger packages.
Sharing a package or sharing a workspace?
One can either share a single package or an entire workspace. I personally think that most of the time one should share the entire workspace instead of the package alone even if you only cloned the other packages from a public Github repo. This might save the receiver a lot of headache e.g. when checking out the wrong branch.
Version control with Git
Arguably the best way to arrange your packages is by using Git. I'd actually make a repository for every package you create (if a couple of packages are virtually inseparable you can also bundled them to a single Git repo or better use metapackages). Then create an additional repository for your workspace and include your own packages and packages from other sources as submodules. This allows your code to be modular and re-usable: You can share only a package or the entire workspace!
As a first step I always add a .gitignore file to each package repository which excludes *.pyc files and another one to the workspace repository that ignores the build, devel and install folders.
You can add a particular repository as submodule to your workspace Git repository by opening a console inside the src folder of your workspace repository and typing
$ git submodule add -b <branch_name> <git_url_to_package> <optional_directory_rename>
Note that you can actually track a particular branch of a repository that you include as a submodule. In case you need a submodule at some point follow this guide.
If you share the workspace repository with someone they will have to have access to each individual submodule repository and they will have to not only pull the repository but also update the submodules with
$ git clone --recurse-submodules <git_url_to_workspace_repository>
and potentially update them to the latest commit with
$ git submodule update --remote
After these two steps they should have a full version of the repository with submodules and they should be able to progress with the steps listed in the section above.
1.1 Unit-testing and continuous integration
Before sharing a repository you will have to verify that everything is working correctly. This can take a decent amount of time, in particular if the code base is large and you are modifying it frequently. In the ideal case you would have to install it on a brand new machine or inside a virtual box in order to make sure that the set-up works which would take quite some time. This is where unit testing comes into play: For every class and function you program you will write a test. This way you can simply run these tests and make sure everything is working correctly. Generally these unit tests will be performed automatically and the working branches merged continuously. Generally the test routines are written with the libraries Boost::Test (C++), GoogleTest (generally used in ROS with C++), unittest (for Python) and QtTest (for GUIs). For ROS launch files there is additionally rostest. How this can be done in ROS is described here and here.
ROSjects
If you do not even want the person you are sending the code to to go through the hassle to set it up you might consider sending them a ROSject. A ROSject is an online virtual ROS environment (by the guys behind The Construct, the main source of ROS courses and of ROS tutorials on Youtube) that can be created and shared very easily from your existing Git repository as can be seen here. The simulation runs entirely in the cloud on a virtual machine. This way the potential of failure is very low but it is not a choice if your code is supposed to run on hardware and not only in simulation.
Docker
If your installation procedure is complex you might as well use a container such as a Docker.
More information about using Docker in combination with ROS can be found here. The Docker container might introduce though a bit of overhead and it is probably no choice for code which should have real-time priority in combination with a real-time patched operating system.
Debian or snap package
Another way of sending somebody a ROS package is by packing it into a Debian or snap package. This process takes a while and is in particular favourable if you want to give your code to a large number of users that should use the code out of the box. Instructions on how this can be done for Debian packages can be found here and here, while a guide for snap can be found here.
I would like to know, how can I install a plugin to Jenkins, using the Jenkins Remote
access API?
I found a way to install using jenkins CLI. But I need to know how to do the same using API.
I tried using jenkins-python library. But I did not find any way to
install plugin there.
Send (HTTP POST) the following xml data (with your plugin-id#version) to Jenkins plugin manager. Check out my jenkins install plugin script on gist.
This HTTP POST request install jenkins git plugin 2.0.
curl -X POST -d '<jenkins><install plugin="git#2.0" /></jenkins>' --header 'Content-Type: text/xml' http://localhost:8080/pluginManager/installNecessaryPlugins
Some plugins are hard to update on the file system because others depend on it (credentials is one example). For such plugins it is only possible to update them using the web interface.
Jenkins frontend has a page under 'Manage Jenkins' -> 'Manage Plugins'. Under the 'Advanced' tab is a form to 'uploadPlugin'. It allows web automation with curl, you might need to add authentication.
curl -i -F file=#pluginfilename.hpi http://jenkinshost/jenkins/pluginManager/uploadPlugin
In addition to the methods already mentioned (I personally used the "curl uploadPlugin" one provided by #bbaassssiiee), you need to consider that if you use pluginManager Jenkins will try to load your plugin dinamically, but in case you need to restart Jenkins to initialize the plugin properly (this was my case), you should add:
curl -kX POST https://${JENKINS_URL}/safeRestart
In case you copy the plugin directly to jenkins/plugin, the restart is mandatory for the plugin to be loaded.
As suggested by malenkiy_scot, we can create a job and use the Jenkins CLI. Here is the secret way I do for my automation in installing plugins. Jenkins plugins are available in the Jenkins mirror here: http://updates.jenkins-ci.org/latest This link might not list anything but you can download the plugin if you know the name of the plugin. For example, if you want to download the skype-notifier plugin, you can download it from http://updates.jenkins-ci.org/latest/skype-notifier.hpi The generic URL is "http://updates.jenkins-ci.org/latest/.hpi"
After downloading that plugin, it should go to the "plugins" directory in Jenkins home on the server. For linux machine, it will most likely be in "/var/lib/jenkins/plugins". Simple example
wget http://updates.jenkins-ci.org/latest/skype-notifier.hpi
mv skype-notifier.hpi /var/lib/jenkins/plugins
There are two things to note here:
If the plugin has any dependencies, those will not be installed by default. If you know what other plugins are required, those can be installed the same way. A bit of manual process is required here. But if a same set of plugins are required, the dependency can be resolved just once and script can be written to download and move them to the Jenkins home.
Downloaded plugins cannot be used right away. A reload of Jenkins is required.
After a lot of blood sweat and tears my suggested solution is:
Download the hpi files (plugin and dependencies) using plugin-installation-manager-tool
(requires java) or install-plugins.sh (requires bash only, but is officially deprecated, though still working 09/2021)
Note: Both are also contained in official docker image (see also Offline Installations)
Then install all downloaded files via
curl -i -F file=#plugin.hpi http://${JENKINS_URL}/pluginManager/uploadPlugin
Why?
POSTing to /pluginManager/installNecessaryPlugins always installs latest version (known bug or feature?) and seems to only install the requested plugin without proper dependency handling.
Simple example
Requires install-plugins.sh and its dependency jenkins-support from jenkinsci/docker.
You have do adapt install-plugins.sh line 27 to point to your jenkins-support file, e.g.
. jenkins-support if you have everything in one folder and execute it from there.
pluginFolder=$(mktemp -d)
# Download plugins
JENKINS_UC=https://updates.jenkins.io REF="${pluginFolder}" \
install-plugins.sh \
docker-workflow:1.26 docker-plugin:1.2.2
# add more plugins in here, pass a bash array or load from file
# (see Real-life example bellow)
# Install all downloaded plugin files via HTTP
for pluginFile in "${pluginFolder}/plugins"/*; do
curl -i -F "file=#${pluginFile}" http://${JENKINS_URL}/pluginManager/uploadPlugin
done
Real-life example
Taken from cloudogu/gitops-playground.
download-plugins.sh - loads all plugins declared in plugins.txt using install-plugins.sh to a directory passed as parameter.
init-jenkins.sh calls download-plugins.sh, then installs the plugins using jenkins-REST-client.sh
I do not think this is possible. However, as a workaround you may consider creating a job that would install plugins via Jenkins CLI; you then can invoke that job via the API with appropriate parameters.
I would like to know, how can I install a plugin to Jenkins, using the Jenkins Remote
access API?
I found a way to install using jenkins CLI. But I need to know how to do the same using API.
I tried using jenkins-python library. But I did not find any way to
install plugin there.
Send (HTTP POST) the following xml data (with your plugin-id#version) to Jenkins plugin manager. Check out my jenkins install plugin script on gist.
This HTTP POST request install jenkins git plugin 2.0.
curl -X POST -d '<jenkins><install plugin="git#2.0" /></jenkins>' --header 'Content-Type: text/xml' http://localhost:8080/pluginManager/installNecessaryPlugins
Some plugins are hard to update on the file system because others depend on it (credentials is one example). For such plugins it is only possible to update them using the web interface.
Jenkins frontend has a page under 'Manage Jenkins' -> 'Manage Plugins'. Under the 'Advanced' tab is a form to 'uploadPlugin'. It allows web automation with curl, you might need to add authentication.
curl -i -F file=#pluginfilename.hpi http://jenkinshost/jenkins/pluginManager/uploadPlugin
In addition to the methods already mentioned (I personally used the "curl uploadPlugin" one provided by #bbaassssiiee), you need to consider that if you use pluginManager Jenkins will try to load your plugin dinamically, but in case you need to restart Jenkins to initialize the plugin properly (this was my case), you should add:
curl -kX POST https://${JENKINS_URL}/safeRestart
In case you copy the plugin directly to jenkins/plugin, the restart is mandatory for the plugin to be loaded.
As suggested by malenkiy_scot, we can create a job and use the Jenkins CLI. Here is the secret way I do for my automation in installing plugins. Jenkins plugins are available in the Jenkins mirror here: http://updates.jenkins-ci.org/latest This link might not list anything but you can download the plugin if you know the name of the plugin. For example, if you want to download the skype-notifier plugin, you can download it from http://updates.jenkins-ci.org/latest/skype-notifier.hpi The generic URL is "http://updates.jenkins-ci.org/latest/.hpi"
After downloading that plugin, it should go to the "plugins" directory in Jenkins home on the server. For linux machine, it will most likely be in "/var/lib/jenkins/plugins". Simple example
wget http://updates.jenkins-ci.org/latest/skype-notifier.hpi
mv skype-notifier.hpi /var/lib/jenkins/plugins
There are two things to note here:
If the plugin has any dependencies, those will not be installed by default. If you know what other plugins are required, those can be installed the same way. A bit of manual process is required here. But if a same set of plugins are required, the dependency can be resolved just once and script can be written to download and move them to the Jenkins home.
Downloaded plugins cannot be used right away. A reload of Jenkins is required.
After a lot of blood sweat and tears my suggested solution is:
Download the hpi files (plugin and dependencies) using plugin-installation-manager-tool
(requires java) or install-plugins.sh (requires bash only, but is officially deprecated, though still working 09/2021)
Note: Both are also contained in official docker image (see also Offline Installations)
Then install all downloaded files via
curl -i -F file=#plugin.hpi http://${JENKINS_URL}/pluginManager/uploadPlugin
Why?
POSTing to /pluginManager/installNecessaryPlugins always installs latest version (known bug or feature?) and seems to only install the requested plugin without proper dependency handling.
Simple example
Requires install-plugins.sh and its dependency jenkins-support from jenkinsci/docker.
You have do adapt install-plugins.sh line 27 to point to your jenkins-support file, e.g.
. jenkins-support if you have everything in one folder and execute it from there.
pluginFolder=$(mktemp -d)
# Download plugins
JENKINS_UC=https://updates.jenkins.io REF="${pluginFolder}" \
install-plugins.sh \
docker-workflow:1.26 docker-plugin:1.2.2
# add more plugins in here, pass a bash array or load from file
# (see Real-life example bellow)
# Install all downloaded plugin files via HTTP
for pluginFile in "${pluginFolder}/plugins"/*; do
curl -i -F "file=#${pluginFile}" http://${JENKINS_URL}/pluginManager/uploadPlugin
done
Real-life example
Taken from cloudogu/gitops-playground.
download-plugins.sh - loads all plugins declared in plugins.txt using install-plugins.sh to a directory passed as parameter.
init-jenkins.sh calls download-plugins.sh, then installs the plugins using jenkins-REST-client.sh
I do not think this is possible. However, as a workaround you may consider creating a job that would install plugins via Jenkins CLI; you then can invoke that job via the API with appropriate parameters.
I came across Nimble yesterday, but couldn't get past Step 1, configuring BuildConfig.groovy to find the Nimble's remote repository.
My BuildConfig.groovy file is one line:
grails.plugin.repos.discovery.intient="http://intient.com/downloads/grails/
Here is the message I get when running grails install-plugin nimble 0.2:
Welcome to Grails 1.1.1 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /opt/dev/sdks/grails-1.1.1
Base Directory: /home/wraith/dev/source/demo
Running script /opt/dev/sdks/grails-1.1.1/scripts/InstallPlugin.groovy
Environment set to development
No authentication for svn repo at intient ...
Reading remote plugin list ...
Reading remote plugin list ...
Reading remote plugin list ...
Plugin 'nimble' was not found in repository. If it is not stored in a configured repository you will need to install it manually. Type 'grails list-plugins' to find out what plugins are available.
This is the first time I have tried to install a plugin not in the official repository. What is the best way to narrow down if it is a problem at Intient.com or with my configuration?
Follow these instructions with the following modifications:
Step 1 is correct
Instead of using the remote repository, download the zipped plugin
Move the plugin to ~/dev/plugins
grails install-plugin ~/dev/plugins/grails-nimble-0.2.zip
Steps 3-5 are correct
We were performing some maintenance on intient.com and the load balancer wasn't providing this content for the last 12 hours or so (oops!).
Should be sorted now but the steps Wraith Monster gave above work for a manual install as well.
Once Grails 1.2 proper hits Nimble will be part of the official plugin repo and we won't need to worry about this at all.
you could always download the zip file for the plugin and install it manually
Download source code from http://github.com/intient/nimble
Unzip under your plugins directory of your project (usually under ${USER_HOME}/.grails/<grails-version>/projects/<myproject>/plugins)
Rename the extracted folder into "nimble-0.2"
Remove from BuildConfig the line grails.plugin.repos.discovery.intient="http://intient.com/downloads/grails/"
Edit the file application.properties of your project and add the line plugins.nimble=0.2
If not installed under your project, you should install the plugins : shiro (version 1.0-SNAPSHOT at least) and mail (>0.6). (run command grails install-plugin <pluginName> <version>)
Start directly from Step 3
It should work (at least, it worked for me). Good luck