{"id":39961013,"url":"https://github.com/tpayne/devops-coord-framework","last_synced_at":"2026-01-18T21:08:11.107Z","repository":{"id":43686650,"uuid":"175008087","full_name":"tpayne/devops-coord-framework","owner":"tpayne","description":"Open-source DevOps framework example for on-boarding 1:N projects Jenkins (or other CI tool) \u0026 CLI use","archived":false,"fork":false,"pushed_at":"2025-12-20T06:05:29.000Z","size":2510,"stargazers_count":9,"open_issues_count":13,"forks_count":8,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-12-20T15:06:40.490Z","etag":null,"topics":["cicd","cicd-feature","cicd-jenkins","cicd-jenkins-test","cicd-promote-to-production","devops","devops-pipeline","devops-services","devops-tools","devops-workflow","jenkins-pipeline","on-boarding","utility-classes","utility-function","utility-library"],"latest_commit_sha":null,"homepage":"","language":"Groovy","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tpayne.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2019-03-11T13:39:48.000Z","updated_at":"2024-11-30T01:08:07.000Z","dependencies_parsed_at":"2023-10-03T01:06:16.471Z","dependency_job_id":"49273b7e-2805-48a2-b9de-9e11e003f1e5","html_url":"https://github.com/tpayne/devops-coord-framework","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/tpayne/devops-coord-framework","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpayne%2Fdevops-coord-framework","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpayne%2Fdevops-coord-framework/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpayne%2Fdevops-coord-framework/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpayne%2Fdevops-coord-framework/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tpayne","download_url":"https://codeload.github.com/tpayne/devops-coord-framework/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpayne%2Fdevops-coord-framework/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28550661,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-18T20:59:07.572Z","status":"ssl_error","status_checked_at":"2026-01-18T20:59:02.799Z","response_time":98,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cicd","cicd-feature","cicd-jenkins","cicd-jenkins-test","cicd-promote-to-production","devops","devops-pipeline","devops-services","devops-tools","devops-workflow","jenkins-pipeline","on-boarding","utility-classes","utility-function","utility-library"],"created_at":"2026-01-18T21:08:10.248Z","updated_at":"2026-01-18T21:08:11.098Z","avatar_url":"https://github.com/tpayne.png","language":"Groovy","readme":"Devops Coordination Framework\n=============================\n\nIf you find this framework useful or would like something added to it, feel free to drop me a comment.\n  \nStatus\n------\n````\nFramework Status: Ready for use\n````\n\nBuild CI/Testing Status\n-----------------------\nThe following indicates the CI and coverage status.\n[SonarCloud](https://sonarcloud.io/dashboard?id=org.devops.framework%3Adevops-framework) analysis is in prototyping.\n\n[![Java CI with Maven](https://github.com/tpayne/devops-coord-framework/actions/workflows/maven.yml/badge.svg)](https://github.com/tpayne/devops-coord-framework/actions/workflows/maven.yml)\n[![CodeQL](https://github.com/tpayne/devops-coord-framework/actions/workflows/codeql-analysis.yml/badge.svg)](https://github.com/tpayne/devops-coord-framework/actions/workflows/codeql-analysis.yml)\n[![pages-build-deployment](https://github.com/tpayne/devops-coord-framework/actions/workflows/pages/pages-build-deployment/badge.svg)](https://github.com/tpayne/devops-coord-framework/actions/workflows/pages/pages-build-deployment)\n[![SonarCloud Code Analysis](https://github.com/tpayne/devops-coord-framework/actions/workflows/codeanalysis.yaml/badge.svg)](https://github.com/tpayne/devops-coord-framework/actions/workflows/codeanalysis.yaml)\n\nContents\n========\n\n* [Overview](#overview)\n* [Framework Objects](#framework-objects)\n* [Service Objects](#service-objects)\n* [So, why have a DevOps framework?](#so-why-have-a-devops-framework)\n\t* [The Problem Statement](#the-problem-statement)\n\t* [The Implementation](#the-implementation)\n* [Framework Process Flows](#framework-process-flows)\n\t* [The Overall Process Flow](#the-overall-process-flow)\n\t* [The CI Process Flow](#the-ci-process-flow)\n\t* [The CD Process Flow](#the-cd-process-flow)\n* [Jenkins and Compiler Support](#jenkins-and-compiler-support)\n* [Framework Classes](#framework-classes)\n\t* [Build Class](#build-class)\n\t* [Deploy Class](#deploy-class)\n\t* [Test Class](#test-class)\n\t* [Integration Class](#integration-class)\n\t* [ReleaseCandidate Class](#releasecandidate-class)\n\t* [CIFramework Class](#ciframework-class)\n\t* [CDFramework Class](#cdframework-class)\n* [How to Install](#how-to-install)\n* [Service Classes](#service-classes)\n\t* [Utilities](#utilities)\n\t* [SCM](#scm)\n\t* [Notifications](#notifications)\n\t* [Container](#container)\n\t* [Repository](#repository)\n\t* [ComponentManifest](#componentmanifest)\n\t* [Provision](#provision)\n* [How to Use](#how-to-use)\n* [Framework Documentation](#framework-documentation)\n* [Class Usage Examples and Running Unit-tests](#class-usage-examples-and-running-unit-tests)\n\t* [Running the unit-tests](#running-the-unit-tests)\n* [Pipeline Examples](#pipeline-examples)\n\t* [Screenshots](#screenshots)\n* [DSL Plugin](#dsl-plugin)\n* [Liability Warning](#liability-warning)\n* [Licensing](#licensing)\n* [Known Issues \u0026 Notes](#known-issues-notes)\n\nOverview\n========\nThis repository delivers a framework that was created to help manage the DevOps process for releases that involve a \nlarge number of components and/or that need a standard process for managing components and how they are delivered.\n\nThe framework provides a set of objects intended to manage each major phase of a CI/CD pipeline into which custom logic\ncan be placed that will then be execute at the correct place, so removing the need for linking jobs together or building\ncustom flow logic into your pipeline.\n\nFor example, a `Build` object is present that allows you to register callbacks for operations like: -\n- Cleaning work areas\n- Getting code\n- Running a build process\n- Running a unit-test process\n- Running a static code analysis process etc.\n\nAll you need to do is register callbacks to do your own specific build logic or unit-test process etc. and the framework\nwill manage all the running of that process and the coordination with other steps.\n\nThe framework also provides a small set of \"most commonly used functions\" service library to help \"kick-start\" your CI/CD\nprocess if needed. These functions include operations like: -\n- Slack notification\n- Email\n- Container services\n- SCM services\n- various file based services\n\nThese can be used (if needed) from Jenkins or command line.\n\nFramework Plugins for Jenkins\n-----------------------------\nThe framework provides two different plugins for Jenkins. The first of these is a shared library which is used to provide\nthe CI/CD framework (and service) objects discussed below. The second is a set of DSL extensions which - if installed \nas a Jenkins plugin - provides a set of DSL extensions which can be used in a Jenkins pipeline syntax. These are also \ndiscussed below.\n\nFramework Objects\n=================\nThe framework is split into two main pipelines: -\n- The CI process for individual products/components \n- The CD process for integrated releases\n\nThe CI process is used to manage the build, deploy and test processes for each individual component and the CD process \nis used to manage the integration and release phases.\n\nThe main interface objects for controlling these phases are shown below: -\n\n\u003e| Class | Description | \n\u003e| ----- | ----------- |\n\u003e| `CIFramework` | Which is used to control your CI process (Build, Deploy and Test process) |\n\u003e| `CDFramework` | Which is used to control your CD process (Integration and Release candidate verification process)|\n\nThe `CIFramework` interface is split into three main phases - each of which are controlled by a specific object: -\n\n\u003e| Class | Description | \n\u003e| ----- | ----------- |\n\u003e| `Build` | Which is used to control your build process |\n\u003e| `Deploy` | Which is used to control your deployment process |\n\u003e| `Test` | Which is used to control your test process |\n\nLikewise, the `CDFramework` interface is split into two main phases - each of which are controlled by a specific object\nas well: -\n\n\u003e| Class | Description | \n\u003e| ----- | ----------- |\n\u003e| `Integration` | Which is used to control your integration process |\n\u003e| `ReleaseCandidate` | Which is used to control your Release candidate process |\n\nThese interface objects allow you to register the callbacks that you want to use for each main process - like build - \nand then the framework will take care of running these callbacks in the correct flow and managing the coordination between\nthe steps.\n\nService Objects\n===============\nThe framework also provides a number of \"service\" objects aimed at providing commonly required DevOps capabilities like \ncloning code, running Docker images, sending emails etc. These services are provided to help make a DevOps implementation\neasier to do by providing working services and utilities that are commonly required.\n\n\u003e| Class | Description | \n\u003e| ----- | ----------- |\n\u003e| `Notifications` | For email and [Slack](https://slack.com) IRC messaging | \n\u003e| `SCM` | For GIT and SVN SCM function(s) - currently only supporting cloning |\n\u003e| `Container` | For various container management commands - currently only supporting [Docker](https://www.docker.com) |\n\u003e| `Repository` | For pushing and pulling files from repos - currently only file, [Artifactory](https://jfrog.com/artifactory/) and [Nexus OSS v2](https://www.sonatype.com/nexus-repository-oss) are supported |\n\u003e| `ComponentManifest` | For maintaining your manifest of integrated components. This is the list of component names, versions, status and locations that you register with the manifest. These can then be accessed later on for usage in other testing or release processes |\n\u003e| `Provision` | For running provisioning scripts - currently only Ansible is supported |\n\nSo, why have a DevOps framework\n===============================\nAs mentioned above, the framework is primarily provided as a way of allowing you to control - in a standard way - \nhow products are on-boarded into CI/CD and how that process is then managed. It does this in two ways. Firstly,\nby providing a standard framework into which product-teams can implement their CI processes, so ensuring everyone\nis using the same guidelines. Secondly, by having the framework manage the process flow of the overall steps and\nthe coordination between them.\n\nThe Problem Statement\n---------------------\nAs an organization with many products or different components in place, transferring these all over to a CI/CD process\nmay be a bit daunting - especially if they each use different types of technologies or build processes. Without a \nframework in place, those products may each end up implementing their own CI/CD process or technology, making the \nmanagement and integration of those products a big challenge.\n\nIntegration of products and the management of that process is also a big problematic area. A release that is made up\nof many products means that you need to track which versions of products have been released, which versions are\nin test and how they can work with each other. If, for example, your release if made up of 20 different products\nmanaging the status and dependencies of those products could be a large task. This is something the framework can\ndo for you by managing the list of components and how they are promoted through the release pipeline.\n\nAlso, by extending the base framework, you can implement specific customisations that you might want to apply\nto every product - like security scans - that cannot be \"forgotten\" or missed when teams implement their own CD\nprocesses.\n\nThe Implementation\n------------------\nThe framework has been implemented using Groovy/Java based callbacks. This means that you can easily integrate it into\nJenkins pipelines as a shared library or use it standalone. The callback mechanism means that virtually any CLI or \nAPI based build technology can be run using it, so it is totally flexible regarding the CI/CD processes it can wrap. \n\nExamples of both standalone and Jenkins pipeline implementations are provided.\n\nFramework Process Flows\n=======================\nThe process flows provided by the framework are described below.\n\nThe Overall Process Flow\n------------------------\nThe overall process flow is that used to implement the CI/CD pipeline. The picture below shows how this works.\n\n\u003e![Overall Process flow](https://github.com/tpayne/devops-framework/blob/master/devops-framework-pipeline/src/main/resources/OverallFrameworkFlow.jpg)\n\nIndividual products use a standard CI build, deploy and test process to verify their changes are working as expected. \nThese are then promoted to the component manifest for further testing in an integrated flow.\n\nIn the context of a release end to end flow, the framework works as shown in the picture below. The CI process is used\nfor feature development and the CD process is used for the release verification. Quality gates are implemented using \nthe test processes to determine if components should be added to the component manifest and to determine if the release\ncandidate can be promoted to production.\n\n\u003e![E2E Process flow](https://github.com/tpayne/devops-framework/blob/master/devops-framework-pipeline/src/main/resources/DevOpsE2EOverview.jpg)\n\n\nThe CI Process Flow\n-------------------\nThe CI process flow controls the component or product-level build, deploy and test process. This pipeline works as\nfollows.\n\n\u003e![CI Process flow](https://github.com/tpayne/devops-framework/blob/master/devops-framework-pipeline/src/main/resources/CIFrameworkProcessFlow.jpg)\n\nWhen a product has finished with the testing process, then it will be promoted to the component manifest to make it a\ncandidate for integration testing.\n\nThe CD Process Flow\n-------------------\nWhen an update is detected to the component manifest, this kicks off the CD flow which then runs the integration and other\nrelease verification processes to ensure that the release stack is ready for deployment to production. This pipeline flow \nis shown below.\n\n\u003e![CD Process flow](https://github.com/tpayne/devops-framework/blob/master/devops-framework-pipeline/src/main/resources/CDFrameworkProcessFlow.jpg)\n\nJenkins and Compiler Support\n============================\nThe framework will only run with the following: -\n- JDK 8+ (javac 1.8.0_201+)\n- Jenkis LTS 2.164.1+\n\nYou can downgrade the versions by modifying the `pom.xml` file, but you will also need to downgrade any dependent plugins.\n\nThe framework has only been compiled and tested using the documented versions above (and the latest versions of Jenkins 2.168).\n\nFramework Classes\n=================\nThe following are the main framework classes and the methods that they have.\n\nBuild Class\n-----------\nThe Build class is provided to control your build process and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `prepareWorkArea()`| A callout provided to help prepare your workarea for a build |\n\u003e| `getCode()`| A callout provided to help you pull your code |\n\u003e| `preBuild()`| A callout provided to help prepare for a build |\n\u003e| `runBuild()`| A callout provided to help run a build process |\n\u003e| `postBuild()`| A callout provided to help run a post build process |\n\u003e| `runUnitTests()`| A callout provided to help run any unit tests |\n\u003e| `evaluateUnitTests()`| A callout provided to help evaluate any unit tests results |\n\u003e| `runStaticCodeTests()`| A callout provided to help run any static code analysis process |\n\u003e| `evaluateStaticCodeTests()`| A callout provided to help evaluate any analysis results |\n\u003e| `bakeImage()`| A callout provided to help bake an image |\n\u003e| `uploadAssets()`| A callout provided to help upload any assets created during the build |\n\u003e| `logResults()`| A callout provided to help log any results | \n\u003e| `promote()`| A callout provided to help promote a build to the next phase | \n\u003e| `runPipeline()`| Run the pipeline |\n\nAll callbacks are run in the above order, no matter how your register them.\n\nDeploy Class\n------------\nThe Deploy class is provided to control your deploy process and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `prepareForDeploy()` | A callout provided to help prepare your environment for a deploy |\n\u003e| `getAssets()` | A callout provided to help you pull your deploy assets |\n\u003e| `preDeploy()` | A callout provided to help prepare for a deploy |\n\u003e| `runDeploy()` | A callout provided to help run a deploy process |\n\u003e| `postDeploy()` | A callout provided to help run a post deploy process |\n\u003e| `runSmokeTests()` | A callout provided to help run any smoke tests |\n\u003e| `evaluateSmokeTests()` | A callout provided to help evaluate any smoke tests results |\n\u003e| `logResults()` | A callout provided to help log any results |\n\u003e| `promote()` | A callout provided to help promote a deploy to the next phase | \n\u003e| `runPipeline()` | Run the pipeline |\n\nAll callbacks are run in the above order, no matter how your register them.\n\nTest Class\n----------\nThe Test class is provided to control your test process and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `prepareForTest()` | A callout provided to help prepare your environment for testing |\n\u003e| `getAssets()` | A callout provided to help you pull your test assets |\n\u003e| `preTest()` | A callout provided to help prepare for a test |\n\u003e| `runTest()` | A callout provided to help run a test process |\n\u003e| `postTest()` | A callout provided to help run a post test process |\n\u003e| `evaluateTests()` | A callout provided to help evaluate any tests results |\n\u003e| `logResults()` | A callout provided to help log any results | \n\u003e| `promote()` | A callout provided to help promote a test to the next phase | \n\u003e| `runPipeline()` | Run the pipeline |\n\nAll callbacks are run in the above order, no matter how your register them.\n\nIntegration Class\n-----------------\nThe Integration class is provided to control your integration process and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `getComponentList()` | A callout provided to help get the component list for processing |\n\u003e| `prepareForDeploy()` | A callout provided to help prepare an environment for use |\n\u003e| `getDeployAssets()` | A callout provided to help pull your deployment assets |\n\u003e| `preDeploy()` | A callout provided to help prepare for the deploy |\n\u003e| `runDeploy()` | A callout provided to help run the deploy |\n\u003e| `postDeploy()` | A callout provided to help perform any post deployment actions |\n\u003e| `runSmokeTests()` | A callout provided to help run smoke tests |\n\u003e| `evaluateSmokeTests()` | A callout provided to help evaluate the smoke test results |\n\u003e| `logDeployResults()` | A callout provided to help log the deployment results |\n\u003e| `prepareForTest()` | A callout provided to help prepare for testing |\n\u003e| `getTestAssets()` | A callout provided to help pull test assets |\n\u003e| `preTest()` | A callout provided to help prepare for the testing |\n\u003e| `runTests()` | A callout provided to help run the testing |\n\u003e| `postTest()` | A callout provided to help perform any post testing activities |\n\u003e| `evaluateTestResults()` | A callout provided to help evaluate test results |\n\u003e| `logTestResults()` | A callout provided to help log test results |\n\u003e| `promote()` | A callout provided to help promote a test to the next phase | \n\u003e| `runPipeline()` | Run the pipeline |\n\nAll callbacks are run in the above order, no matter how your register them.\n\nReleaseCandidate Class\n----------------------\nThe ReleaseCandidate class is provided to control your release process and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `getComponentList()` | A callout provided to help get the component list for processing |\n\u003e| `prepareForDeploy()` | A callout provided to help prepare an environment for use |\n\u003e| `getDeployAssets()` | A callout provided to help pull your deployment assets |\n\u003e| `preDeploy()` | A callout provided to help prepare for the deploy |\n\u003e| `runDeploy()` | A callout provided to help run the deploy |\n\u003e| `postDeploy()` | A callout provided to help perform any post deployment actions |\n\u003e| `runSmokeTests()` | A callout provided to help run smoke tests |\n\u003e| `evaluateSmokeTests()` | A callout provided to help evaluate the smoke test results |\n\u003e| `logDeployResults()` | A callout provided to help log the deployment results |\n\u003e| `prepareForTest()` | A callout provided to help prepare for testing |\n\u003e| `getTestAssets()` | A callout provided to help pull test assets |\n\u003e| `preTest()` | A callout provided to help prepare for the testing |\n\u003e| `runTests()` | A callout provided to help run the testing |\n\u003e| `postTest()` | A callout provided to help perform any post testing activities |\n\u003e| `evaluateTestResults()` | A callout provided to help evaluate test results |\n\u003e| `logTestResults()` | A callout provided to help log test results |\n\u003e| `rollback()` | A callout provided to help perform a rollback if required |\n\u003e| `finish()` | A callout provided to help perform any final actions if needed |\n\u003e| `runPipeline()` | Run the pipeline |\n\nAll callbacks are run in the above order, no matter how your register them.\n\nIn addition, every callback takes the following parameters: -\n\n\u003e| Parameter | Description | \n\u003e| --------- | ----------- |\n\u003e| `body:{}` | Used to specify the Groovy code to run the process |\n\u003e| `finalHandler:{}` | Used to specify any Groovy code which will be invoked after the process has run |\n\u003e| `exceptionHandler:{}` | Used to specify any Groovy code which will be invoked if any exception occurs |\n\nCIFramework Class\n-----------------\nThe CIFramework class is provided to control your CI process and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `setBuild()` | A callout provided to set your build object into the CI framework for processing |\n\u003e| `getBuild()` | A callout provided to get your build object from the CI framework |\n\u003e| `setDeploy()` | A callout provided to set your deploy object into the CI framework for processing |\n\u003e| `getDeploy()` | A callout provided to get your deploy object from the CI framework |\n\u003e| `setTest()` | A callout provided to set your test object into the CI framework for processing |\n\u003e| `getTest()` | A callout provided to get your test object from the CI framework |\n\u003e| `launchCI()` | A callout provided to run the CI process |\n\nCDFramework Class\n-----------------\nThe CDFramework class is provided to control your CD process and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `setIntegration()` | A callout provided to set your integration object into the CD framework for processing |\n\u003e| `getIntegration()` | A callout provided to get your integration object from the CD framework |\n\u003e| `setReleaseCandidate()` | A callout provided to set your release candidate object into the CD framework for processing |\n\u003e| `getReleaseCandidate()` | A callout provided to get your release candidate object from the CD framework |\n\u003e| `launchCD()` | A callout provided to run the CD process |\n\nHow to Install\n==============\nTo install this [Jenkins share library](https://jenkins.io/doc/book/pipeline/shared-libraries), do the following...\n\n\t1) git clone https://github.com/tpayne/devops-framework.git\n\t2) cd devops-framework\n\t3) mvn package\n\t4) cd devops-framework-pipeline/target/\n\t5) Unzip devops-framework-pipeline-dsl-pack.zip into a working directory\n\t6) Use the instructions in the Jenkins Wiki (https://jenkins.io/doc/book/pipeline/shared-libraries/#global-shared-libraries) to install the shared library into your Jenkins system\n\nYou will need to configure the unit-tests as discussed below and install/configure `Docker` and `Ansible` as they are used\nduring the test process. If you want to just build the packages without doing any unit-tests, then you can do this via...\n\n\tmvn clean package -Dmaven.test.skip=true\n\t\nThis will build the packages only.\n\nThe Jenkins DSL HPI plugin will automatically be built via the `mvn package` command. The HPI file is situated in the \n`devops-framework-plugin/target` directory and is loaded into Jenkins using the advanced plugin manager option in \nthe Jenkins management console. This is the same as any standard file-based Jenkins plugin.\n\nService Classes\n===============\nThe following are the main service classes and the methods that they have.\n\nUtilities\n---------\nThis class provides various useful utilities that are used and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `isUnix()` | Used to detect UNIX based OS |\n\u003e| `isWindows()` | Used to detect Windows based OS |\n\u003e| `mapProperties()` | Used to map a properties file into a Map |\n\u003e| `getDefaultProperties()` | Used to read any default properties that might have been setup for the framework to use |\n\u003e| `readAllBytes()` | Used to read a file into memory as an array of bytes. Mostly for binary files |\n\u003e| `readFile()` | Used to read a text file into memory as a string |\n\u003e| `writeFile()` | Used to write strings or bytes to a file |\n\u003e| `getExecutable()` | Used to locate an executable file in the path and return a File object to it |\n\u003e| `runCmd()` | Used to run a shell command and trap any output if wanted |\n\u003e| `getTmpDir()` | Used to return a File object to the temporary directory setup on the machine |\n\u003e| `deleteDirs()` | Used to emulate rm -fr  |\n\u003e| `copyFile()` | Used to copy files  |\n\u003e| `copyDirectories()` | Used to copy directories  |\n\u003e| `getFileExt()` | Used to get a file extension  |\n\u003e| `calcFileMD5()` | Used to get a calculate a file's MD5 checksum  |\n\nSCM\n---\nThis class provides all the SCM related support and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `scmClone()` | Used for cloning code from supported SCM repos like Git or SVN |\n\nNotifications\n-------------\nThis class provides notification related functionality and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `sendMail()` | Used for sending email text or HTML/text notifications |\n\u003e| `messageSlackChannel()` | Used for sending notifications to Slack |\n\t\nContainer\n---------\nThis class provides container related functionality and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `createContainerRegistry()` | Used to create a container register for supported platforms like Docker |\n\u003e| `pushContainer()` | Used to push an image to a container register |\n\u003e| `tagContainer()` | Used to tag a container for future use |\n\u003e| `deleteContainerRegistry()` | Used to delete a container register |\n\u003e| `pullContainerImage()` | Used to pull a container image from somewhere |\n\u003e| `deleteContainerImage()` | Used to delete a container image |\n\u003e| `runContainer()` | Used to run a container |\n\u003e| `buildContainer()` | Used to build or bake a container from a given build file |\n\nRepository\n----------\nThis class provides repository related functionality and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `pullAssetFromRepo()` | Used to pull an asset from a repo |\n\u003e| `pushAssetToRepo()` | Used to push an asset to a repo |\n\t\n\nComponentManifest\n-----------------\nThis class provides repository related functionality for maintaining your component manifest list (used in releases) and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `isValid()` | Used to check the manifest is valid |\n\u003e| `getRepo()` | Used to get the repo file details |\n\u003e| `setRepo()` | Used to set the repo file details |\n\u003e| `getCommitComment()` | Used to get the last commit comment |\n\u003e| `getCommitter()` | Used to get the last committer |\n\u003e| `getCommitDate()` | Used to get the last commit date |\n\u003e| `getManifestVersion()` | Used to get the manifest version |\n\u003e| `setManifestVersion()` | Used to set the manifest version |\n\u003e| `getManifestStatus()` | Used to get the manifest status |\n\u003e| `setManifestStatus()` | Used to set the manifest status |\n\u003e| `getComponentList()` | Used to get the list of components registered in the manifest |\n\u003e| `getComponent()` | Used to get the details for an individual component |\n\u003e| `addComponent()` | Used to add a component to the manifest |\n\u003e| `updateComponent()` | Used to update the details for an individual component registered in the manifest |\n\u003e| `removeComponent()` | Used to remove a component from the manifest |\n\u003e| `convertManifestToJSON()` | Used to convert the component manifest to a JSON string |\n\u003e| `commit()` | Used to commit the manifest details to the repo file |\n\nThe manifest file (by default) is a JSON file stored in the repository file. This manifest file looks like this: -\n\n\t{\n\t  \"commitComment\": \"Committed version 30 by user1 at 13:20:12 27/03/2019\",\n\t  \"compList\": {\n\t    \"gitplugin\": {\n\t      \"componentVersion\": \"1553692812066\",\n\t      \"componentName\": \"gitplugin\",\n\t      \"componentLocation\": \"/Volumes/WorkDisk/tmp/Repos/github.hpi.1553692812066\",\n\t      \"componentStatus\": \"Integration Test\",\n\t      \"componentMd5Sum\": \"9f8628f68ce0865348ade6d2a4d568af\"\t      \n\t    },\n\t    \"dimensionsscm\": {\n\t      \"componentVersion\": \"1553692305487\",\n\t      \"componentName\": \"dimensionsscm\",\n\t      \"componentLocation\": \"/Volumes/WorkDisk/tmp/Repos/dimensionsscm.hpi.1553692305487\",\n\t      \"componentStatus\": \"Integration Test\",\n\t      \"componentMd5Sum\": \"7251e4a7b0d77264940db7baa8c58756\"\t      \n\t    },\n\t    \"JavaAppCICD\": {\n\t      \"componentVersion\": \"1553609424273\",\n\t      \"componentName\": \"JavaAppCICD\",\n\t      \"componentLocation\": \"/Volumes/WorkDisk/tmp/Repos/jpetstore.war.1553609424273\",\n\t      \"componentStatus\": \"Integration Test\",\n\t      \"componentMd5Sum\": \"db8c6088e5e789db8c850075d98dc373\"\t      \n\t    }\n\t  },\n\t  \"committer\": \"user1\",\n\t  \"status\": \"Integration Test\",\n\t  \"version\": \"30\",\n\t  \"commitUTCDate\": 1553692812367\n\t}\n\nThere are a number of parts to it as follows: -\n\n\u003e| Key | Description | \n\u003e| --- | ----------- |\n\u003e| `commitComment` | Used to hold the last commit comment |\n\u003e| `compList` | Used to hold the registered components |\n\u003e| `committer` | Used to register who did the last commit |\n\u003e| `status` | Used to hold the current status |\n\u003e| `version` | Used to hold the current version |\n\u003e| `commitUTCDate` | Used to hold the last commit date/time in UTC format |\n\nThe `compList` is formatted as: -\n\n\u003e| Key | Description | \n\u003e| --- | ----------- |\n\u003e| `\u003ccomponentKey\u003e` | Used to hold the component key, e.g. JavaAppCICD |\n\u003e| `componentVersion` | Used to hold the registered component version |\n\u003e| `componentName` | Used to hold the registered component name |\n\u003e| `componentLocation` | Used to hold the registered component location, i.e. where it is stored |\n\u003e| `componentStatus` | Used to hold the registered component status |\n\u003e| `componentMd5Sum` | Used to hold the registered component MD5 checksum |\n\nThe values of these keys are free text and are set by the appropriate `set...()` methods. What formats\nyou use are up to you.\n\nFurther keys can be added by modifying the `ComponentManifest.groovy` file as needed.\n\nProvision\n----------\nThis class provides provisioning related functionality and has the following methods: -\n\n\u003e| Method | Description | \n\u003e| ------ | ----------- |\n\u003e| `runPlaybook()` | Used to run a play/runbook (Ansible only) |\n\nHow to Use\n==========\nThe shared library works by providing controller classes that you can use in a pipeline job. As such, you need \nto create a pipeline job and register the callbacks that you want to use.\n\nFor example, a sample pipeline might look like\n\n\t// Sample pipeline...\n\t@Library('devops-framework')\n\timport org.devops.*\n\t\n\t// Include the core services as I want to use them as well...\n\t@GrabResolver(name='devops-core', root='file:///Volumes/WorkDisk/GROOVY/devops-framework/devops-framework-core/target/lib/')\n\t@Grab('org.devops.framework.core:devops-framework-core:0.0.1-SNAPSHOT')\n\t\n\t// Import the framework core classes...\n\timport org.devops.framework.core.*\n\n\tdef config = [\n\t    property1: 'value1',\n\t    property2: 'value2',\n\t    property3: 'value3'\n\t]\n\n\tdef bld = new org.devops.Build(this, config)\n\n\tnode {    \n\t        File fetchDir = new File(\"/Volumes/WorkDisk/tmp/BuildJobs/\")\n\t\tString scmURI = \"https://github.com/sourcerepo/JavaAppCICD.git\"\n\t\tString slackURI = \"https://hooks.slack.com/services/SDJSHETEJDKRJFHFIDLODJFF\"\n\n\t\t// Register my build process...    \n\t\tbld.runBuild(body:{\n\t\t    // This is a Maven which will compile and run all the unit tests as\n\t\t    // part of the process, so we do not need all the other build callbacks...\n\t\t    println \"\u003eRun build...\u003c\"\n\t\t    sh(script: \"cd ${fetchDir.getAbsolutePath()}; chmod +rx ./mvnw; ./mvnw -q package\")\n\t\t}, finalHandler:{ println \"\u003eBuild Job Done\u003c\" })\n\n\t\t// Register my get code callback...\n\t\tbld.getCode(body:{\n\t\t    println \"\u003eGet code - cloning from GIT...\u003c\"\n\t\t    StringBuffer outputStr = new StringBuffer()\n\t\t    boolean retStat = SCM.scmClone(ConfigPropertiesConstants.SCMGIT,\n\t\t\t\t\t\t    scmURI,fetchDir,outputStr)\n\t\t    if (retStat) {\n\t\t\tprintln \"Code clone worked\"\n\t\t\tNotifications.messageSlackChannel(slackURI,\"${label}: Clone worked\")\n\t\t    } else {\n\t\t\tprintln \"Code clone failed\"\n\t\t\tprintln outputStr.toString()\n\t\t\tNotifications.messageSlackChannel(slackURI,\"${label}: Code clone failed - \"+outputStr.toString())\n\t\t    }  \n\t\t    outputStr = null\n\t\t}) \n\n\t\t// Register my bake callback...\n\t\tbld.bakeImage(body:{ println \"\u003eRun my bake\u003c\" })\n\n\t\t// Register a prepareWorkArea callback...\n\t\tbld.prepareWorkArea(body:{\n\t\t    println \"\u003ePrepare Work Area - clean my files up...\u003c\"\n\t\t    if (fetchDir.exists()) {\n\t\t\tUtilities.deleteDirs(fetchDir)\n\t\t    }\n\t\t    fetchDir.mkdirs()\n\t\t})\n\n\t\t// Run my pipeline...\n\t\tbld.runPipeline()\n\t}\n\nThis will run the `prepareWorkArea()`, `getCode()`, `runBuild()` and `bakeImage()` callbacks in this\norder.\n\nA DSL plugin example would look like this\n\n\t// Sample DSL plugin calls...\n\tnode {\n\n\t    // Clone code...\n\t    stage('clone') {\n\t\t// Some constants...\n\t\tString fetchDirG = \"/Volumes/WorkDisk/tmp/BuildJobs/git/\"\n\t\tString fetchDirS = \"/Volumes/WorkDisk/tmp/BuildJobs/svn/\"\n\t\tString scmURI = \"https://github.com/jenkinsci/dimensionsscm-plugin.git\"\n\t\t// Which host is the script running on?\n\t\tsh label: '', script: 'uname -a; hostname'\n\n\t\tdef status = devOpsFrameworkGitCloneStep repoName: scmURI,\n\t\t\t targetDir: fetchDirG\n\t\tprintln status\n\n\t\tstatus = devOpsFrameworkSvnCloneStep repoName: scmURI,\n\t\t\t targetDir: fetchDirS\n\t\tprintln status\n\t    }\n\n\t    // Container ops with Docker...\n\t    stage('container-ops') {\n\n\t\tdef status = devOpsFrameworkPullContainerStep containerName: 'tomcat'\n\t\tprintln status\n\n\t\tstatus = devOpsFrameworkRunContainerStep cmdStr: 'ls -l /',\n\t\t\t\tcontainerName: 'tomcat'\n\t\tprintln status\n\n\t\tstatus = devOpsFrameworkPushContainerStep imageName: 'pushImage'\n\t\tprintln status\n\n\t\tstatus = devOpsFrameworkTagContainerStep containerName: 'tomcat',\n\t\t\t\t\ttargetName: 'yumi-target'\n\t\tprintln status\n\n\t\tstatus = devOpsFrameworkRmContainerStep containerName: 'tomcat', force: true\n\t\tprintln status\n\n\t\tstatus = devOpsFrameworkBuildContainerStep buildDirectory: '/home/Jenkins/workspace/TestDSL/',\n\t\t\t\tcontainerFile: '/home/Jenkins/workspace/TestDSL/DockerFileSuse.test',\n\t\t\t\tcontainerName: 'dsfsdf'\n\t\tprintln status\n\n\t\t// Ansible - not container op...\n\t\tstatus = devOpsFrameworkAnsibleRunbookStep hostFile: '/etc/ansible_hosts',\n\t\t\t    runFile: '/tmp/playbook.yml',\n\t\t\t    workingDir: '/tmp'\n\t\tprintln status\n\t    }\n\t}\n\t\nFramework Documentation\n=======================\nThe framework code comes with some limited JavaDoc present which can be used to generate API documentation\nby using the command\n\n\t% mvn gplus:generateStubs gplus:groovydoc\n\nThis will generate JavaDoc style comments in the `target/` directory\n\nClass Usage Examples and Running Unit-tests\n===========================================\nVirtually all the class functions documented above have example [unit/functional tests](https://github.com/tpayne/devops-framework/tree/master/devops-framework-core/src/test/java/org/devops/framework/core) which are run in the Maven test phase.\n\nYou can use these as examples to show you how to use the classes. \n\nRunning the unit-tests\n----------------------\nThe values used in the unit-tests for things like slack channels and GitHub repos are currently hardcoded to working values.\nHowever, these will need to be changed if you wish to run the tests. These values are located in a properties file \n[`unitTest.properties`](https://github.com/tpayne/devops-framework/blob/master/devops-framework-core/src/test/resources/unitTest.properties). \n\nThese will need to be modified to values more specific for you otherwise some of the tests may fail.\n\n(Note - The tests have very little documentation imbedded in them currently. This will be added slowly).\n\nPipeline Examples\n=================\nExamples of pipelines created using the framework can be found in the [`examples`](https://github.com/tpayne/devops-framework/tree/master/devops-framework-pipeline/examples) directory.\n\n\u003e| Example | Description | \n\u003e| ------ | ----------- |\n\u003e| [`buildJenkinsPluginPipeline.txt`](https://github.com/tpayne/devops-framework/tree/master/devops-framework-pipeline/examples/buildJenkinsPluginPipeline.txt) | Example build pipeline that fetches code, builds it, commits it to a repo, then updates a component manifest with the new version |\n\u003e| [`buildJenkinsPluginPipelineWithSlackNotif.txt`](https://github.com/tpayne/devops-framework/tree/master/devops-framework-pipeline/examples/buildJenkinsPluginPipelineWithSlackNotif.txt) | As `buildJenkinsPluginPipeline.txt`, but also includes Slack channel notifications and shows how the component manifest can track many different components |\n\u003e| [`CIJenkinsPluginPipeline.txt`](https://github.com/tpayne/devops-framework/tree/master/devops-framework-pipeline/examples/CIJenkinsPluginPipeline.txt) | Example build pipeline that fetches code, builds it, commits it to a repo, creates a baked Docker image, then updates a component manifest with the new version. It is implemented using the CIFramework object |\n\u003e| [`IntegrationTestPlugin.txt`](https://github.com/tpayne/devops-framework/tree/master/devops-framework-pipeline/examples/IntegrationTestPlugin.txt) | Example integration pipeline that fetches binaries from the component manifest, bakes a Docker image using them, then tests the container. It is implemented using the Integration object |\n\u003e| [`DSLPipelineExamples.txt`](https://github.com/tpayne/devops-framework/blob/master/devops-framework-pipeline/examples/DSLPipelineExamples.txt) | Example DSL using the Jenkins DSL extension plugin |\n\u003e| [`ExampleComponentManifestRepo.json`](https://github.com/tpayne/devops-framework/blob/master/devops-framework-pipeline/examples/ExampleComponentManifestRepo.json) | Example component manifest file |\n\nScreenshots\n-----------\nSome screenshots of the various jobs are shown below\n\n**Build test case**\n\nThe following is an example run using the Build object.\n\n\u003e![Build Test case](https://github.com/tpayne/devops-framework/blob/master/devops-framework-pipeline/examples/BuildTestCase.jpg)\n\n**CI Framework test case**\n\nThe following is an example run using the CIFramework object.\n\n\u003e![CIFramework Test case](https://github.com/tpayne/devops-framework/blob/master/devops-framework-pipeline/examples/CIFrameworkTestCase.jpg)\n\n**Integration test case**\n\nThe following is an example run using the Integration object.\n\n\u003e![Integration Test case](https://github.com/tpayne/devops-framework/blob/master/devops-framework-pipeline/examples/IntegrationTestCase.jpg)\n\nDSL Plugin\n==========\nAs well as the framework objects above, the framework also provides a HPI DSL plugin which when loaded into Jenkins (as a\nnormal plugin) adds a number of service steps which can be used in your Jenkins pipeline to get your CI/CD process\noff the ground. These service steps are as follows.\n\n\u003e| Step DSL | Description | \n\u003e| -------- | ----------- | \n\u003e| `devOpsFrameworkBuildContainerStep` | This step provides a way of building container images (Docker) | \n\u003e| `devOpsFrameworkPullContainerStep` | This step provides a way of pulling container images (Docker) | \n\u003e| `devOpsFrameworkRunContainerStep` | This step provides a way of running container images (Docker) | \n\u003e| `devOpsFrameworkRmContainerStep` | This step provides a way of removing container images (Docker) | \n\u003e| `devOpsFrameworkTagContainerStep` | This step provides a way of tagging container images (Docker) | \n\u003e| `devOpsFrameworkSvnCloneStep` | This step provides a way of cloning a branch from a SVN repo | \n\u003e| `devOpsFrameworkGitCloneStep` | This step provides a way of cloning a branch from a GIT repo | \n\u003e| `devOpsFrameworkFilePushStep` | This step provides a way of pushing an asset to a file-based repo | \n\u003e| `devOpsFrameworkFilePullStep` | This step provides a way of pulling an asset to a file-based repo | \n\u003e| `devOpsFrameworkNexusPushStep` | This step provides a way of pushing an asset to a Nexus-based repo | \n\u003e| `devOpsFrameworkNexusPullStep` | This step provides a way of pulling an asset to a Nexus-based repo | \n\u003e| `devOpsFrameworkArtifactoryPushStep` | This step provides a way of pushing an asset to a Artifactory-based repo | \n\u003e| `devOpsFrameworkArtifactoryPullStep` | This step provides a way of pulling an asset to a Artifactory-based repo | \n\u003e| `devOpsFrameworkAnsibleRunbookStep` | This step provides a way of running an Ansible playbook |\n\u003e| `devOpsFrameworkShellCmdStep` | This step provides a way of running a shell command | \n\u003e| `devOpsFrameworkShellFileStep` | This step provides a way of running a shell script |\n\nAll these plugins support master and slave configurations.\n\nPlugin Syntax\n-------------\nThe above steps have the following syntax: -\n\n###### Building a container image\n\n_Name:_ `devOpsFrameworkBuildContainerStep`\n\n_Purpose:_ This step is for building a container image from a makefile\n\n_Example:_\n\n\tdevOpsFrameworkBuildContainerStep buildDirectory: '/tmp', \n\t\tcontainerFile: '/tmp/Dockerfile', containerName: 'tomcat'\n\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `buildDirectory` | `'\u003csomeDirectory\u003e'` | Mandatory parameter to specify which directory to run the build in |\n| `containerFile` | `'\u003cfileName\u003e'` | Optional parameter to specify which build file to use. The default is Dockerfile |\n| `containerName` | `'\u003ccontainerName\u003e'` | Mandatory parameter to specify the container name to build |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\n###### Pulling a container image\n\n_Name:_ `devOpsFrameworkPullContainerStep`\n\n_Purpose:_ This step is for pulling a container image from a repo\n\n_Example:_\n\n\tdevOpsFrameworkPullContainerStep containerName: 'tomcat'\t\n\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `containerName` | `'\u003ccontainerName\u003e'` | Mandatory parameter to specify the container name to pull |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\n###### Running a container image\n\n_Name:_ `devOpsFrameworkRunContainerStep`\n\n_Purpose:_ This step is for running a container image with a command\n\n_Example:_\n\n\tdevOpsFrameworkRunContainerStep cmdStr: 'df -H', containerName: 'tomcat'\t\n\n_Parameters:_ \n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `containerName` | `'\u003ccontainerName\u003e'` | Mandatory parameter to specify the container name to run |\n| `cmdStr` | `'\u003ccommandString\u003e'` | Mandatory parameter to specify the command string to run |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\n###### Removing a container image\n\n_Name:_ `devOpsFrameworkRmContainerStep`\n\n_Purpose:_ This step is for deleting a container image from the local repo\n\n_Example:_\n\n\tdevOpsFrameworkRmContainerStep containerName: 'tomcat', force: true\n\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `containerName` | `'\u003ccontainerName\u003e'` | Mandatory parameter to specify the container name to delete |\n| `force` | `'\u003ctrue or false\u003e'` | Optional parameter to force the container to be removed |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\n###### Tagging a container image\n\n_Name:_ `devOpsFrameworkTagContainerStep`\n\n_Purpose:_ This step is for tagging a container image \n\n_Example:_\n\n\tdevOpsFrameworkTagContainerStep containerName: 'tomcat', targetName: 'taggedTomcat'\t\n\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `containerName` | `'\u003ccontainerName\u003e'` | Mandatory parameter to specify the container name to tag |\n| `targetName` | `'\u003ctargetName\u003e'` | Mandatory parameter to specify the target tag |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\t\n###### Clone SVN Repo\n\n_Name:_ `devOpsFrameworkSvnCloneStep`\n\n_Purpose:_ This step is for cloning the code from a SVN repository \n\n_Example:_\n\n\tdevOpsFrameworkSvnCloneStep repoName: 'http://svnrepo.net/mycode/', targetDir: '/tmp/', \n\t\tuserName: 'user1', userPwd: 'user1Pwd'\n\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `repoName` | `'\u003crepoName\u003e'` | Mandatory parameter to specify the repo to clone|\n| `targetDir` | `'\u003csomeDirectory\u003e'` | Optional parameter to specify the target directory to use |\n| `userName` | `'\u003cuserName\u003e'` | Optional parameter to specify a valid SCM username |\n| `userPwd` | `'\u003cpassword\u003e'` | Optional parameter to specify a valid SCM user password |\n\n###### Clone GIT Repo\n\n_Name:_ `devOpsFrameworkGitCloneStep`\n\n_Purpose:_ This step is for cloning the code from a GIT repository \n\n_Example:_\n\n\tdevOpsFrameworkGitCloneStep repoName: 'https://github.com/myuser/myrepo.git', \n\t\ttargetDir: '/tmp/', userName: 'user1', userPwd: 'user1Pwd'\n\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `repoName` | `'\u003crepoName\u003e'` | Mandatory parameter to specify the repo to clone |\n| `targetDir` | `'\u003csomeDirectory\u003e'` | Optional parameter to specify the target directory to use |\n| `userName` | `'\u003cuserName\u003e'` | Optional parameter to specify a valid SCM username |\n| `userPwd` | `'\u003cpassword\u003e'` | Optional parameter to specify a valid SCM user password |\n\n###### Pull File Repo\n\n_Name:_ `devOpsFrameworkFilePullStep`\n\n_Purpose:_ This step is for pulling files from a file-based repo \n\n_Example:_\n\n\tdevOpsFrameworkFilePullStep srcFile: '/Volumes/FileRepo/ASD/Releases/latest/asd.hpi', \n\t\ttargetFile: '/Volumes/WorkArea/Compon_ASD/target/'\n\t\t\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `srcFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify a file or directory to pull |\n| `targetFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the target |\n\n###### Push File Repo\n\n_Name:_ `devOpsFrameworkFilePushStep`\n\n_Purpose:_ This step is for pushing files to a file-based repo \n\n_Example:_\n\n\tdevOpsFrameworkFilePushStep srcFile: '/Volumes/WorkArea/Compon_ASD/target/asd.hpi', \n\t\ttargetFile: '/Volumes/FileRepo/ASD/Releases/latest/'\n\t\t\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `srcFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify a file or directory to push |\n| `targetFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the target |\n\n###### Pull Nexus Repo\n\n_Name:_ `devOpsFrameworkNexusPullStep`\n\n_Purpose:_ This step is for pulling files from a Nexus-based repo \n\n_Example:_\n\n    devOpsFrameworkNexusPullStep srcFile: 'http://localhost:8081/nexus/sites/generic-local/comp/Asd.war', \n        targetFile: '/Volumes/WorkDisk/deploy/ASD.war', \n        userName: 'admin', userPwd: 'admin123'\n\t\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `srcFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify a file to pull from Nexus |\n| `targetFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the target |\n| `userName` | `'\u003cuserName\u003e'` | Optional parameter to specify a valid repo username |\n| `userPwd` | `'\u003cpassword\u003e'` | Optional parameter to specify a valid repo user password |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\n###### Push Nexus Repo\n\n_Name:_ `devOpsFrameworkNexusPushStep`\n\n_Purpose:_ This step is for pushing files to a Nexus-based repo \n\n_Example:_\n\n    devOpsFrameworkNexusPushStep srcFile: '/Volumes/WorkArea/Compon_ASD/target/asd.war',\n        targetFile: 'http://localhost:8081/nexus/sites/generic-local/comp/Asd.war',\n        userName: 'admin', userPwd: 'admin123'\n\t\t\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `srcFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the file to push to Nexus |\n| `targetFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the target |\n| `userName` | `'\u003cuserName\u003e'` | Optional parameter to specify a valid repo username |\n| `userPwd` | `'\u003cpassword\u003e'` | Optional parameter to specify a valid repo user password |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\n###### Pull Artifactory Repo\n\n_Name:_ `devOpsFrameworkArtifactoryPullStep`\n\n_Purpose:_ This step is for pulling files from a Artifactory-based repo \n\n_Example:_\n\n    devOpsFrameworkArtifactoryPullStep srcFile: 'http://localhost:8081/artifactory/generic-local/comp/Asd.war', \n        targetFile: '/Volumes/WorkDisk/deploy/ASD.war', \n        userName: 'admin', userPwd: 'admin123'\n\t\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `srcFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify a file to pull from Artifactory |\n| `targetFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the target |\n| `userName` | `'\u003cuserName\u003e'` | Optional parameter to specify a valid repo username |\n| `userPwd` | `'\u003cpassword\u003e'` | Optional parameter to specify a valid repo user password |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\n###### Push Artifactory Repo\n\n_Name:_ `devOpsFrameworkArtifactoryPushStep`\n\n_Purpose:_ This step is for pushing files to a Artifactory-based repo \n\n_Example:_\n\n    devOpsFrameworkArtifactoryPushStep srcFile: '/Volumes/WorkArea/Compon_ASD/target/asd.war',\n        targetFile: 'http://localhost:8081/artifactory/generic-local/comp/Asd.war',\n        userName: 'admin', userPwd: 'admin123'\n\t\t\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `srcFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the file to push to Artifactory |\n| `targetFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the target |\n| `userName` | `'\u003cuserName\u003e'` | Optional parameter to specify a valid repo username |\n| `userPwd` | `'\u003cpassword\u003e'` | Optional parameter to specify a valid repo user password |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\n###### Run an Ansible Playbook\n\n_Name:_ `devOpsFrameworkAnsibleRunbookStep`\n\n_Purpose:_ This step is for running an Ansible playbook\n\n_Example:_\n\n    devOpsFrameworkAnsibleRunbookStep hostFile: '/Volumes/WorkDisk/resources/ansible_hosts',\n        workingDir: '/Volumes/WorkDisk/tmp/',\n        runFile: '/Volumes/WorkDisk/resources/ansible_playbook.yml'\n\t\t\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `hostFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the hosts file to use |\n| `runFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify the playbook to use |\n| `workingDir` | `'\u003cdirName\u003e'` | Optional parameter to specify a working directory |\n\n###### Run any Shell script\n\n_Name:_ `devOpsFrameworkShellCmdStep`\n\n_Purpose:_ This step is for running any shell script\n\n_Example:_\n\n\tdevOpsFrameworkShellCmdStep script: '''\n                        ls /tmp; echo 1; echo 2; echo 3''', \n                        workingDir: '/tmp/', quiet: true\t\t\n\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `script` | `'\u003cshell script\u003e'` | Mandatory parameter to specify shell script to run|\n| `workingDir` | `'\u003cdirName\u003e'` | Optional parameter to specify a working directory |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\n###### Run any Shell Script File\n\n_Name:_ `devOpsFrameworkShellFileStep`\n\n_Purpose:_ This step is for running any shell script file\n\n_Example:_\n\n\tdevOpsFrameworkShellFileStep cmdFile: '/users/alexgray/build.sh', \n                        workingDir: '/tmp/', quiet: true\n\t\t\t\n_Parameters:_\n\n| Parameter | Value | Description |\n| --------- | ----- | ----------- |\n| `cmdFile` | `'\u003cfileName\u003e'` | Mandatory parameter to specify shell file to run|\n| `workingDir` | `'\u003cdirName\u003e'` | Optional parameter to specify a working directory |\n| `quiet` | `true` | Optional parameter to suppress stdout reporting |\n\nLiability Warning\n=================\nThe contents of this repository (documents and examples) are provided “as-is” with no warrantee implied \nor otherwise about the accuracy or functionality of the examples.\n\nYou use them at your own risk. If anything results to your machine or environment or anything else as a \nresult of ignoring this warning, then the fault is yours only and has nothing to do with me.\n\nLicensing\n=========\nThis software is licensed using the terms and provisions of the [MIT license](https://en.wikipedia.org/wiki/MIT_License).\n\nKnown Issues Notes\n==================\nThe following are known issues: -\n- The framework has not been fully ported or tested on Windows. Do not be surprised if some work needs to be done to make it work on that OS. Where possible classes have been written to support both UNIX and Windows, but they have not been tested on Windows, so some issues may occur. The framework was developed and tested on Unix.\n- The Jfrog-cli is not currently supported in the Artifactory classes. This will be added later on.\n- Currently, the framework can run both with in and without of Jenkins (if so required), but this duality is not guaranteed to be maintained in the future.\n- Container singletons have been provided to show how they can be created, but these have not been verified in usage\n- Due to a \"feature\" with Jenkins, any process which takes 5+ mins to run will be killed by Jenkins. This is core Jenkins pipeline and cannot be overriden without writing a custom threading plugin. The Jenkins developers seem to regard long running jobs as errors. To overcome this you will need to use the DevOps-framework DSL plugin for Jenkins. DSL functions have been added that provide the same functionality, but remove the time issue.\n- Any changes on this branch are automatically built \u0026 unit-tested for completeness using Travis-CI. If you want to view the job history, click on the 'build' status icon at the beginning on this README.\n- This LTS version is a limited implementation only. Services like K8s support and multi-cloud deployment are not available. However, feel free to implement them on top of the existing services.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftpayne%2Fdevops-coord-framework","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftpayne%2Fdevops-coord-framework","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftpayne%2Fdevops-coord-framework/lists"}