Skip to content

Latest commit

 

History

History
87 lines (64 loc) · 5.24 KB

CONTRIBUTING.md

File metadata and controls

87 lines (64 loc) · 5.24 KB
Raw

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a code of conduct that we ask you to follow in all your interactions with the project.

IMPORTANT: Please do not create a Pull Request without creating an issue first.

Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.

Thank you for your pull request. Please provide a description above and review the requirements below.

Pull Request Process

  1. Check out Pull Request Checklist, ensure you have fulfilled each step.
  2. Check out guidelines below, the project tries to follow these, ensure you have fulfilled them as much as possible.
  3. Ensure any install or build dependencies are removed before the end of the layer when doing a build.
  4. Please ensure the README and DOCS are up-to-date with details of changes to the command-line interface, this includes new environment variables, exposed ports, used file locations, and container parameters.
  5. PLEASE ENSURE YOU DO NOT INTRODUCE BREAKING CHANGES.
  6. PLEASE ENSURE BUG FIXES AND NEW FEATURES INCLUDE TESTS.
  7. You may merge the Pull Request in once you have the sign-off of one other maintainer/code owner, or if you do not have permission to do that, you may request the second reviewer to merge it for you.

Pull Request Checklist

  • Read the CONTRIBUTING document. (It's checked since you are already here.)
  • Read the CODE OF CONDUCT document.
  • Add tests to cover changes.
  • Ensure your code follows the code style of this project.
  • Ensure CI and all other PR checks are green OR
    • Code compiles correctly.
    • Created tests which fail without the change (if possible).
    • All new and existing tests passed.
  • Add your changes to Unreleased section of CHANGELOG.
  • Improve and update the README (if necessary). The same file will be updated in plugin index when your PR is accepted, so it will be available for end-users at http://plugins.drone.io.
  • Ensure documentation is up-to-date.

Release Process

Only concerns maintainers/code owners

  1. PLEASE DO NOT INTRODUCE BREAKING CHANGES

  2. Execute make README.md. This will update usage section of README.md with latest CLI options

  3. Increase the version numbers in any examples files and the README.md to the new version that this the release would represent. The versioning scheme we use is SemVer for versioning. For the versions available, see the tags on this repository.

  4. Ensure CHANGELOG is up-to-date with new version changes.

  5. Update version references.

  6. Create a tag on the master. Any changes on the master will trigger a release with the given tag and `latest tag.

    $ git tag -am 'vX.X.X'
> ...
$ git push --tags
> ...

  7. Check whether all the generate artifacts in-place properly.

  8. (OBSOLETE) Update plugin index using DOCS.

Keep in mind that users usually use the latest tagged images in their pipeline, please make sure you do not interfere with their working workflow.

Testing Locally

Want to test locally without opening a PR? Follow the steps below to build a local image of drone-cache and run the Drone pipeline against it.

  1. Make sure you have the Drone CLI, Docker, and GoReleaser installed locally.
  2. Update the image_templates key in drone-cache/.goreleaser-local.yml to reflect the name you'd like your image to have, then run goreleaser release --config=.goreleaser-local.yml --snapshot --skip-publish --rm-dist to build the image.
  3. Update the image: drone-cache:MyTestTag entries in the local-pipeline pipeline in the .drone.yml with the name of the image that you created (there are several of these).
  4. Run the Drone pipeline locally with drone exec ./.drone-local.yml --branch MyBranchName

Response Times

Please note the below timeframes are response windows we strive to meet. Please understand we may not always be able to respond in the exact timeframes outlined below

  • New issues will be reviewed and acknowledged with a message sent to the submitter within two business days
    • Please ensure all of your pull requests have an associated issue.
  • The ticket will then be groomed and planned as regular sprint work and an estimated timeframe of completion will be communicated to the submitter.
  • Once the ticket is complete, a final message will be sent to the submitter letting them know work is complete.

Please feel free to ping us if you have not received a response after one week