Is Behat compatible with Jenkins and Maven.Can it be easily integrated? if not , then which BDD frameworks integrate well with Jenkins
Thanks
The simplest way to get jenkins running your behat suite is to use a shell script. Providing you've got a PHP environment setup on your jenkins host and the project dependancies installed through composer, you can specify a simple command such as bin/behat. This will run your behat feature suite, returning an error code if the suite fails. Jenkins should pick this up and fail your job too.
In my experience, having a specific profile in behat.yml for specifying formatters and parameters is useful. As a result your command may look something like: bin/behat --profile ci
You can of course wrap these commands in something like maven or rake and instead of running a shell script in your jenkins job, you can invoke a rake/maven etc task. I use rake for my projects as it's much easier to maintain your build when it starts doing more than just running behat.
Related
I didn't know composer before laravel and i encountered them at the same time. So, I can't distinguish the commands of them, but memorize them.
What is the difference between php artisan and composer.phar and also the commands they run?
Can anyone help me on this issue? Thanks..
Composer is a package manager for php and artisan is a command line tool using php
Composer
- download libraries
Artisan
- run scripted commands like you would in bash
The reason to use artisan instead of direct php commands is that you have to implement certain functions so you get an universal feel to the commands. It will help with a lot of things like handling arguments. You could see it as a nice helper for writing great php command line tools.
Once your command is generated, you should fill out the name and
description properties of the class, which will be used when
displaying your command on the list screen.
The fire method will be called when your command is executed. You may
place any command logic in this method.
https://laravel.com/docs/5.0/commands
There is a basic difference in these two commands that they belongs to two different packages.
Composer: composer is a dependency management tool for php. It auto manages dependencies of your project according to your requirements and thus makes your project more distributable.
You don't have to package all the dependencies inside your application. And, if your dependencies are variable it is hard to manage them all within your application. So, composer does it for you.
So, your composer command operates this package. And, it can be used for any project whether it is laravel or other php application.
Artisan: This is the command line utility of Laravel. It comes integrated with your laravel installation.
You can perform operations on your laravel project using its commands. As it is a tool built over php. So, you need to execute its command over php-CLI. That is why you use the php before it.
And, you need to use artisan before it because this is the script name which operates the commands of this tool. If you see your laravel project directory it has a file named artisan inside the root folder. It is the file which bootstraps the laravel's command line code. Or, you can say it is like index.php of directory.
Hope I was helpful.
I'm a newbie with Gulp, I made a some custom tasks and would like to launch any task from any HTML, PHP, AngularJS application.
Is it possible? I try to find some feature at Google but I can't look nothing about it.
Gulp is mainly meant to run as a development tool. You usually run some tasks during build or pre-deploy.
Having said that, it is possible to run gulp from php just as any external process, using exec or shell_exec, provided that your node or nvm environment is properly setup.
To execute gulp directly from within php is something probably unable to do as gulp requires node.js.
Basically what I'm trying to do is to create a simple multi-node env with varnish+nginx+mariadb+memcached. By now I've managed to launch the environment and attach git project to it. The problem is that we work with php and symfony2, which requires composer to be executed at least once in order to properly deploy the application.
Outside of jelastic we use Jenkins + Ant (but we don't scale horizontally in automatic on the projects where this setup is used, so it's not a problem to add node manually).
So the question is: How can I run composer or ant with build.xml on each deploy?
I see that Java environments have a build server option, is there something like this for php environments?
PHP projects do not have a "standard" build server in the way that many Java projects do - requirements for PHP build tools are more varied depending on the particular project.
For example one customer may ask for grunt, another for ant, and another for phing.
If you want to perform a sophisticated build, you can create your own build node for your PHP project using an Elastic VPS or separate Docker environment. To deploy the built project to your servers you can use SSH connections, or simply git push and set the runtime environment to auto-update (e.g. via ZDT feature) from that git repo / branch.
If your needs are more simple, you can install composer directly onto your php runtime node in the normal way via SSH.
E.g.
$ curl -sS https://getcomposer.org/installer | php
There are more detailed tips about how to tidy that up (add to your PATH etc.) at http://kb.layershift.com/jelastic-install-composer
I'd like to run phpunit on an external server, the feed those results into a Jenkins plugin like the Clover PHP Coverage Report action.
The code base has some library dependancies that the owner of the Jenkins server does not want deployed.
Well with some tweaking I guess it is possible to make use of the monitoring external plugin. You will have to figure something out to get the files on the jenkins server.
An other option is, if the server owner is willing, to create a specific build agent for your needs. That doesn't affect his jobs and you can use your builds like you want.
Yes, library dependencies shouldn't be installed globally on a Jenkins server, but this is where Composer comes into play: You'd essentially install exactly the dependencies your current software needs locally in the workspace of your job.
Nobody should be bothered by this, because you could also include the needed library code there manually - or even worse, you could use the same file and class names and code something entirely different. All of this must not interfere with any other job running on that same server, and it doesn't.
You can't really avoid Composer, because PHPUnit will stop being distributed via PEAR, as well as some Symfony components that are being used. Better go to the Composer project page and learn how to use it. By the way: You can include the needed version of PHPUnit with Composer as well, so you need not rely on a centrally installed version (which is hard to update because there are so many jobs that would need updates then - too much work in one go).
I have Jenkins setup to build and deploy my project using Phing.
Inside the Phing build.xml file, I create a set of targets for doing useful stuff, such as running tests, static code analyzer and such.
Phing also is responsible for deploying the application, creating a structure similar to this:
var/www
current -> /var/www/develop/releases/20100512131539
releases
20100512131539
20100509150741
20100509145325
features
hotfixes
The thing is, Jenkins does a git clone of the project and Phing also does it, inside the releases directory. With this, I have two clones on the same build and deploy process.
My question is: the responsibility of cloning the repository should be of Phing or Jenkins?
I leave Phing the same sort of tasks you mentioned: like static code analyzer, running tests, linters, etc.
The reason for this, is that as a dev, I might want to run all these test (or a set of them) regularly during my development, and Im able to trigger them on my local environment without the need of jenkins.
For deployment stuff, I leave jenkins in charge of it, so would leave jenkins to continue doing it.
But, if you want to have everything in phing, I think that would be ok, too. I would split the tasks to have a group of dev test to be run on console, and a jenkins tasks to be run on the deploy.
Definitively, only one of them should be doing so.