Skip to content

Latest commit

 

History

History
98 lines (71 loc) · 4.73 KB

CONTRIBUTING.md

File metadata and controls

98 lines (71 loc) · 4.73 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).

Release Process

Only concerns maintainers/code owners

  1. PLEASE DO NOT INTRODUCE BREAKING CHANGES

  2. Update README.mdwith the latest changes.

  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. This will trigger drone build and new images are pushed into DockerHub with the version references.

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

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

You can build and run the plugin locally through the CLI (you will need a GitHub token with the ‘repo’ scope)

$ cd drone-convert-pathschanged
$ openssl rand -hex 16
2ea1d6ca0df30bf3957ad1c0de441f0d
$ ./scripts/build.sh
$ docker build -t pathschanged -f docker/Dockerfile.linux.amd64 .
$ docker run --rm -e DRONE_DEBUG=true -e DRONE_SECRET=2ea1d6ca0df30bf3957ad1c0de441f0d -e PROVIDER=github -e TOKEN=REDACTED --name=converter -p 3000:3000 -it pathschanged

Then you can send to this endpoint by using plugins comandset:

$ export DRONE_CONVERT_SECRET=2ea1d6ca0df30bf3957ad1c0de441f0d
$ export DRONE_CONVERT_ENDPOINT=http://localhost:3000
$ drone plugins convert --path .drone.yml --before _SHA_ --after _SHA_ --ref refs/heads/changeset --repository owner/repo

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