accenture/adop-platform-management

What is Platform Management?

The platform management repository includes the Jenkins jobs and supporting scripts that facilitate:

• Cartridges
• Multi-tenancy via workspaces & projects

This repository is loaded into the platform using the baked in "Load_Platform" job and contains:

• Jenkins Job DSL - defines the Jenkins jobs for workspaces, projects, and cartridges
• Jenkins Groovy scripts - for automating the configuration of Jenkins
• Shell Scripts - for automating command line actions, such as with Gerrit or LDAP

License

Please view license information for the software contained on this image.

User feedback

Documentation

Documentation will be captured within this README.md and this repository's Wiki.

Issues

If you have any problems with or questions about this image, please contact us through a GitHub issue.

Contribute

You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can.

Before you start to code, we recommend discussing your plans through a GitHub issue, especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give you feedback on your design, and help you find out if someone else is working on the same thing.

adop-platform-management's Issues

Support embedded cartridges

Pom files don't get their own repo. Perhaps Cartridges don't always need on either. How about the cartridge loader goes a recursive find for the first metadata.cartridge file and it finds and treats that as the cartridge root?

Happy to implement but only if you'll accept this.

I recognise I will need to think about avoiding the repo getting loaded twice (once as the local copy of the cartridge and once if someone re-states it in the urls.txt file).

[Modification_request] Authorize Job to copy artifact from other job

Hello,

I've just deployed the platform on a fresh Debian VM. When I've commit my modification of the spring-petclinic example project by a git commit (and so, triggered the pipeline) the job "Reference_Application_Code_Analysis" failed with the following error:

ERROR: Unable to find a build for artifact copy from: Reference_Application_Unit_Tests

I've solved this issue by manually allowing the artifacts from the Reference_Application_Unit_Tests job to get copied by the Reference_Application_Code_Analysis job. This options is displayed in the job configuration screen and is provided by the "Copy Artifacts" plugin.

If the problem is confirmed, the groovy file should be probably modified accordingly.

Thanks

Error while running Project_Management/Generate_Project job in newly setup Gen5 platform

Hi Team,

I am facing below error while running Generate_Project job in newly setup Gen5 instance. Please help me out with this ASAP as its impacting client deliverable timelines:

Processing DSL script jobs.groovy
[ssh-agent] Stopped.
ERROR: (jobs.groovy, line 30) No signature of method: javaposse.jobdsl.dsl.helpers.BuildParametersContext.extensibleChoiceParameterDefinition() is applicable for argument types: (jobs$_run_closure2_closure4_closure9) values: [jobs$_run_closure2_closure4_closure9@63f207a9]
Finished: FAILURE

Extensible choice editable dropdown for the cartridge URL?

Jenkins already has the extensible choice plugin:
https://wiki.jenkins-ci.org/display/JENKINS/Extensible+Choice+Parameter+plugin

As you can see here:
https://wiki.jenkins-ci.org/download/attachments/65669637/extensible-choice-parameter-global-configuration.png?version=1&modificationDate=1431758568000
It supports editable dropdowns.

This would mean people can load custom cartridges without editing the job.

The only downside I see is that the extensible choice plugin doesn't natively support job dsl, so this would take a:
configure { project ->
style insert in the DSL to get it working.

Happy to do this but only if the PR would be accepted.

/cc @anton-kasperovich @nickdgriffin

Enhancement: Load_Cartridge updated so it accepts a commitish object to use

I think it would be beneficial for it to be possible to select a commitish object to load a cartridge from, rather than it default to master.

I would expect the following behaviour:

• When a commitish object is provided it will checkout that version of the cartridge repository and proceed to load it
• When a commitish object is not provided the behaviour defaults to checking out the master branch - this could just be achieved by defaulting the parameter

This would allow cartridges to be versioned so that if desired only set versions are consumed rather than the latest.

GitLab Load Platform and Platform Management

Hi, I'm John Arcy Teodoro, an Accenture DevOps resource in the PDC.

We've been using the ADOP Generation 5, and made some customization wherein we use GitLab instead of Gerrit. With this, we've edited the docker-compose file of the Gen5 for it to come with GitLab.

Using GitLab as our SCM Tool, we have customized this platform management as well, such that it will be compatible with GitLab. Basically we have just transformed the shell scripts to configure Gerrit into GitLab API calls.

Here are the links for the customized Load Platform and Platform Management:
https://github.com/arcyteodoroacn/adop-b-framework-gitlab-load-platform
https://github.com/arcyteodoroacn/adop-b-framework-gitlab-platform-management

When re-loading cartridge repositories are overwritten

This is typically the scenario below:

1. I create a new project and load the cartridge (which loads in the jobs and the repositories)
2. I update the repositories for code/config etc
3. I re-run the cartridge as I've made a change on the Jenkins job, and it overwrites my repository to the base

Maybe we could flag overwrite and default it to false?

Then maybe later down the line, maybe adding support to pull the "core" and merge the repository from github into your local ADOP (more advanced).

Gen5 Dashboard Selenium URL doesn't work

Hi Team

Gen5 Selenium URL doesnt work directly.

As a workaround, when we replace Domain name in the URL with Public IP, it works.

Any suggestion or resolution to correct this ?

Optional Workspaces

There are use cases where a workspace isn't necessary for users when using ADOP so it would be useful to "opt-out" of using them.

I think this could be achieved by generalising the "Generate_Workspace" job so that it allows creating either a workspace or a project directly, via a dropdown to pick the type.

Enhancement: Extend cartridge collections to include custom cartridge properties and cartridge versioning

I think the cartridge collection functionality should be extended to include support for the following two capabilities:

• Custom cartridge properties (#52)
• Cartridge versioning (#57)

This enables a "cartridges as code" mentality where a collection can be used to version the loading of a cartridges along with their properties.

Enhancement: Platform extension type for Jenkins Pipeline libraries

I think it would be useful to have a platform extension type that would load in Jenkins Pipeline libraries into the Global Pipeline Library so that Pipeline jobs can consume them.

Pluggable SCM Library Versioning

I think the Pluggable SCM library should be versioned so that the Setup_Pluggable_Library job checks out a "known" version so that we insulate against change creeping in.

This came to mind when working on #11.

Cartridge/Platform extensions dependency management

As a user/developer I want to know when my platform extension/cartridge/platman version depends on a specific version of ADOP core as this may prevent the platform extension from being loaded correctly.

An example of this issue is that PR #22 adding docker based platform support - the platform extension and platman require a specific version of nginx.

I imagine a platform extension depending on a specific version of platman and the core depending on a specific version of platman (or vice versa).

Platman dependency version could be defined in the platform extensions/cartridges metadata (version x.y.z or git commit ref etc). The current platform version could be stored in Jenkins as a global environment variable. The load cartridge/platform extensions Jenkins jobs would then first check if the current version of platman and ADOP core are supported by the platform extension. If not, inform the user that they need to perform a platform upgrade. This will enable Jenkins job to fail fast if versions are not compatible.

@nickdgriffin What are your opinions on this?

Generate_Project does not create the Load_Cartridge_Collection job when using Jenkins job DSL plugin version 1.58.

It was worth noting that the project Load_Cartridge_Collection Groovy DSL is only compatible with Jenkins Job DSL plugin version ~1.48. I have seen issues with the Generate_Project job failing when generating the Load_Cartridge_Collection job with plugin version 1.58.

hardcoded ldap host

I am not able to use adop-platform-management with an external LDAP because LDAP host is hardcoded in some scripts. For example in generate_workspace job:

${WORKSPACE}/common/ldap/load_ldif.sh -h ldap -u "${LDAP_ADMIN_USER}" -p "${LDAP_ADMIN_PASSWORD}" -b "${DC}" -f "${OUTPUT_FILE}"

Migration to a fresh plugins

This topic for everyone who is afraid of upgrade plugins button. Hope this will save someones time

1. Changes in DSL for Groovy scripts

• workflowJob is replaced by pipelineJob
• relativeTargetDir is replaced by relativeTargetDirectory and have to be enclosed in extensions block

extensions {
	relativeTargetDirectory('platform-management')
}

• scriptText is replaced by script and have to be enclosed in groovyScript block (with additional sandbox option)

systemGroovyChoiceListProvider {
    groovyScript {
        script("")
        sandbox(false)
    }
}

2. Changes in scripts to approve
   Signatures already approved:

field java.util.ArrayList size
method com.michelin.cio.hudson.plugins.rolestrategy.RoleBasedAuthorizationStrategy addRole java.lang.String com.michelin.cio.hudson.plugins.rolestrategy.Role
method com.michelin.cio.hudson.plugins.rolestrategy.RoleBasedAuthorizationStrategy assignRole java.lang.String com.michelin.cio.hudson.plugins.rolestrategy.Role java.lang.String
method com.michelin.cio.hudson.plugins.rolestrategy.RoleBasedAuthorizationStrategy getRoleMap java.lang.String
method com.michelin.cio.hudson.plugins.rolestrategy.RoleMap getRole java.lang.String
method groovy.lang.GString plus java.lang.String
method groovy.lang.Script println java.lang.Object
method hudson.model.Run getEnvironment hudson.model.TaskListener
method hudson.model.Saveable save
method java.lang.Class getDeclaredMethod java.lang.String java.lang.Class[]
method java.lang.reflect.AccessibleObject setAccessible boolean
method jenkins.model.Jenkins getAuthorizationStrategy
new com.michelin.cio.hudson.plugins.rolestrategy.Role java.lang.String java.lang.String java.util.Set
staticField com.michelin.cio.hudson.plugins.rolestrategy.RoleBasedAuthorizationStrategy PROJECT
staticMethod hudson.model.Hudson getInstance
staticMethod hudson.security.Permission fromId java.lang.String
staticMethod jenkins.model.Jenkins getInstance

Signatures already approved which may have introduced a security vulnerability (recommend clearing):

method java.lang.Class getDeclaredMethod java.lang.String java.lang.Class[]
staticMethod hudson.model.Hudson getInstance
staticMethod jenkins.model.Jenkins getInstance

Feel free to add information here regarding upgrade to a fresh plugins versions

Cartridge Loader should allow generic Key Value pair params

ENHANCEMENT:
As a Jenkins developer, I want to load a cartridge collection and have it receive a Key-value pair map that will be passed on to each loaded cartridge in the collection.

Currently, the Cartridge loader receives a JSON payload specifying the cartridge URLs and the Folder names.

The proposed is to add either an extended choice or multi-line string parameter to inject collection params at load time. This would allow for example to load a set of cartridges for a specific target environment.