GitHub Repositories

The CloudSlang project consists of the following repositories on GitHub with the dependencies depicted in the diagram below.

Dependency diagram

Repository Dependencies

  • score - CloudSlang Orchestration Engine (Score)
    • dependency-management
    • engine
    • package
    • runtime-management
    • score-api
    • score-samples
    • score-tests
    • worker
  • cloud-slang - CloudSlang and the CLI
    • build
    • cloudslang-all
    • cloudslang-cli
    • cloudslang-commons
    • cloudslang-compiler
    • cloudslang-content-maven-compiler
    • cloudslang-content-verifier
    • cloudslang-entities
    • cloudslang-runtime
    • cloudslang-spi
    • cloudslang-tests
cloud-slang Repository Structure
  • cloud-slang-content - CloudSlang flows and operations
    • ci-env
    • configuration/properties/io/cloudslang
    • content/io/cloudslang
      • amazon
        • aws
          • ec2
      • base
        • cmd
        • comparisons
        • datetime
        • examples
        • filesystem
        • http
        • json
        • lists
        • mail
        • maps
        • math
        • network
        • os
        • print
        • remote_file_transfer
        • scripts
        • ssh
        • strings
        • utils
        • xml
      • chef
      • ci
        • circleci
      • consul
      • coreos
      • couchbase
      • digital_ocean
        • v2
      • docker
      • git
      • google
        • compute
      • hashicorp
        • vault
      • haven_on_demand
      • heroku
      • itsm
        • service_now
      • jenkins
      • marathon
      • maven
      • microfocus
        • dca
      • microsoft
        • azure
      • new_relic
        • servers
      • openshift
      • openstack
      • slack
      • stackato
      • twilio
        • sms
      • vmware
        • vcenter
      • (other integrations to be added as new folders)
  • cs-actions - Java @Action classes used by CloudSlang
    • cs-amazon
    • cs-azure
    • cs-commons
    • cs-couchbase
    • cs-microfocus-dca
    • cs-database
    • cs-date-time
    • cs-google
    • cs-http-client
    • cs-json
    • cs-lists
    • cs-mail
    • cs-powershell
    • cs-rft
    • cs-ssh
    • cs-utilities
    • cs-vmware
    • cs-xml
  • score-content-sdk - SDK for developing Java @Actions
    • src/main/java/com/hp/oo/sdk/content
      • annotations
      • plugin
        • ActionMetadata
  • test-functional - Global functional tests for CLI and builder
  • CloudSlang-Docker-Image - CloudSlang Docker image
  • - CloudSlang website
  • docs - CloudSlang documentation
  • atom-cloudslang-package - Atom package for CloudSlang support
  • cloudslang-cli - npm cloudslang-cli
  • cs-intellij-plugin - CloudSlang Intellij Plugin
  • cs-content-generator - Tool to convert Java Actions to .sl files
  • cs-content-packager - Tool to package CloudSlang content

Contribution Guide

We welcome and encourage community contributions to CloudSlang. Please familiarize yourself with the Contribution Guidelines and Project Roadmap before contributing.

There are many ways to help the CloudSlang project:

  • Report issues
  • Fix issues
  • Improve the documentation

Contributing Code

The best way to directly collaborate with the project contributors is through GitHub:

  • If you want to contribute to our code by either fixing a problem or creating a new feature, please open a GitHub pull request.
  • If you want to raise an issue such as a defect, an enhancement request or a general issue, please open a GitHub issue.

All patches from all contributors get reviewed.

After a pull request is made, other contributors will offer feedback. If the patch passes review, a maintainer will accept it with a comment.

When a pull request fails testing, the author is expected to update the pull request to address the failure until it passes testing and the pull request merges successfully.

At least one review from a maintainer is required for all patches (even patches from maintainers).

Content contributions which require environments that are difficult to setup may be accepted as beta content. Beta content is not verified or tested by the CloudSlang team. Beta content is named with the beta_ prefix. The community is encouraged to assist in setting up testing environments for the beta content.

See the file in the relevant repository for additional guidelines specific to that repository.

Developer’s Certificate of Origin

All contributions must include acceptance of the DCO:

Developer Certificate of Origin Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 660 York Street, Suite 102, San Francisco, CA 94110 USA

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Developer’s Certificate of Origin 1.1

By making a contribution to this project, I certify that:

  1. The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
  2. The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
  3. The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
  4. I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

Sign your work

To accept the DCO, simply add this line to each commit message with your name and email address (git commit -s will do this for you):

Signed-off-by: Jane Example <>

For legal reasons, no anonymous or pseudonymous contributions are accepted.

Pull Requests

We encourage and support contributions from the community. No fix is too small. We strive to process all pull requests as soon as possible and with constructive feedback. If your pull request is not accepted at first, please try again after addressing the feedback you received.

To make a pull request you will need a GitHub account. For help, see GitHub’s documentation on forking and pull requests.

Normally, all pull requests must include tests that validate your change. Occasionally, a change will be very difficult to test. In those cases, please include a note in your commit message explaining why tests are not included.


Whether you are a regular contributor or a newcomer, we care about making this community a safe place for you.

We are committed to providing a friendly, safe and welcoming environment for all regardless of their background and the extent of their contributions.

Please avoid using nicknames that might detract from a friendly, safe and welcoming environment for all. Be kind and courteous.

Those who insult, demean or harass anyone will be excluded from interaction. In particular, behavior that excludes people in socially marginalized groups will not be tolerated.

We welcome discussion about creating a welcoming, safe and productive environment for the community. If you have any questions, feedback or concerns please let us know. (