Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

How to Contribute

We welcome your contribution. Please get involved and help make this a better tool for everyone! You don't necessarily need to contribute code, there are lots of ways you can help out..

Contact us!

Please get in contact if you're able to contribute in any way jenkins-build-pipeline@centrumsystems.com.au or geoffb@centrumsystems.com.au or twitter: CentrumSystems

Testing

Have a look for the latest pre-release version Build Pipeline Plugin - Roadmap and test it out in your environment.

  • bugs for the official release version should be raised in Jenkins JIRA with the build-pipeline component
  • bugs during development should be raised on the site that the pre-release version is downloaded from

Documentation

We are a bit short on good doco. Some areas that seem in most need of some more content are:

  • Passing parameters along a pipeline
  • Building your artefacts once and reusing along the pipeline

Tell us how you're using it

Write about how you get the most out of this plugin. Share your blog entries with us centrum@twitter.com

Fixes and Enhancements

If you'd like to help with development, there is plenty to do... Get in contact.

Tell us what you need

Please add wishlist items to the Build Pipeline Plugin - Roadmap page

Contributing code - suggestions and demands

Pull requests

Please send pull requests through the jenkinsci/build-pipeline-plugin github repository. Before doing so, please ensure you've at least done the following:

  • run "mvn clean install" against the latest version
  • created unit tests
  • tested locally

We will try and accommodate these as often as it is worthwhile putting a release together.

Want to become a committer?

email us. The more the merrier

Feature Flags

Please use feature flags if you can, and where it makes sense

Why bother?

This will achieve a couple of things.

  1. It allows us to keep the UI uncluttered, but still support requirements for specialist use cases. A lot of requests for featires on the pipeline are only valid in certain environments. Having them configurable allows the UI to stay uncluttered and easy to understand.
  2. It might keep the plugin more stable. A new feature that doesn't work in a particular scenario that wasn't covered during testing can be switched off until a fix is made - rather than having to roll back the plugin and not having the other features available.
How?

If you are developing a new feature, simply have a configuration parameter in the view to show and hide it. Please have it switched off by default...

It may make sense to refactor these out later if it is the desired behaviour for everyone to always have a feature available.

  • No labels