Name: Version-Analysis-Of-Composer-Dependencies
Owner: AOE
Description: null
Forked from: sandritter/Version-Analysis-Of-Composer-Dependencies
Created: 2018-05-09 13:24:31.0
Updated: 2018-05-09 13:24:33.0
Pushed: 2016-11-09 14:09:50.0
Homepage: null
Size: 97630
Language: Java
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
This plugin can be used for build jobs which install dependencies via PHP composer followed by testing those dependencies e.g through unit tests. This plugin reads out the resulting composer.lock file which is located inside the particular workspace of a build job. The composer.lock file includes all dependencies together with their installed versions. The dependencies and their versions will be stored related to the specific build to a sqlite database. Hence, the database keeps track of the dependencies and their versions which are tested during a specific build.
Imagine you and your team are developing a bunch of components which are going to be integrated to one system using PHP composer and continuous integration. Some of the components have dependencies to other components of the system. The system has grown big, so the effort of maintaining a cross-system integration test is getting too high.
The functionality of the system is assured through modular integration tests. This will be accomplished by the build jobs of the several components of the system. A build job includes loading the sources of the component (e.g from a git or svn repository) and install all dependencies in their latest version via composer. Afterwards, the component including its dependencies is tested (e.g through unit tests).
So what can happen? Imagine you are developing three components: component A,B and C. These components are part of your system. Component B and C are dependent on component A. Whenever the build job for component B or C is runnig, component A is loaded as a dependency via composer. Let's take a look at it in a chronological sequence.
It's Thursday the first of january 1970. The build job of component C is running at 12:30 PM with the following version information: component C in version 3.6 component A in version 2.0
The build job of component A is running at 13:00 PM with the following version information: component A in version 2.1
The build job of component B is running at 13:30 PM with the following version information: component B in version 1.4 component A in version 2.1
Again, the build job of component A is running at 14:00 PM with the following version information: component A in version 2.2
Finally, all components in their latest version will be integrated to the system at 15:00 PM: component C in version 3.6 component B in version 1.4 component A in version 2.2
Remember that no cross-system integration test exists. The components and their dependencies are only tested in modular integration tests during their builds. That means that component C in version 3.6 and component B in version 1.4 have never been tested against component A in version 2.2 through modular integration tests.
To be capable to track those incidents, this plugin has been developed. The plugin will display the disparities between a version of components that have been tested against each other and a version of components that have been installed during another integration build using the same components. That information tells you which integration build needs to be excuted again to ensure that all components are tested against each other.
Run
'''
$ mvn hpi:hpi
'''
to create the version-analysis-of-build-dependencies.hpi
To install:
1. copy the resulting **./target/version-analysis-of-build-dependencies.hpi** file to the $JENKINS_HOME/plugins directory. Don't forget to restart Jenkins afterwards.
2. or use the plugin management configuration to upload the hpi file. You have to restart Jenkins in order to find the pluing in the installed plugins list.
1. Go to your JENKINS_HOME directory. Usually for Unix the JENKINS_HOME directory is located at /var/lib/jenkins and for Mac OS X at /Users/Shared/Jenkins/Home.
'''
e.g $ cd /var/lib/jenkins
'''
2. Instantiate the sqlite database with the given create.sql:
'''
$ sudo sqlite3 <databaseName>.db < <directory of>/create.sql
'''
3. Change the access rights for the database file
'''
$ sudo chmod 0755 <databaseName>.db
$ sudo chown jenkins:jenkins <databaseName>.db
'''
4. Add the absolute path of the database file to the global configuration of the plugin. You will find this settings in the jenkins system configuration.
will follow soon
will follow soon