Welcome! There are many ways to contribute, including submitting bug reports, improving documentation, submitting feature requests, reviewing new submissions, or contributing code that can be incorporated into the project.
Please follow instruction.
If you are not a member of a development team building Evacuator, you should create a fork before making any changes.
Please follow instruction.
Open terminal and run these commands:
git clone git@github.com:myuser/evacuator.git -b develop
cd evacuator
Create virtualenv and install dependencies:
# create virtual environment
python -m venv venv
source venv/bin/activate
pip install -U wheel
pip install -U pip setuptools
# install requirements
pip install -U \
-r requirements-dev.txt \
-r requirements-docs.txt \
-r requirements-test.txt
Install pre-commit hooks:
pre-commit install --install-hooks
Test pre-commit hooks run:
pre-commit run
# run tests
pytest
Build documentation using Sphinx:
cd docs
make html
Then open in browser docs/_build/index.html
.
Please create a new GitHub issue for any significant changes and enhancements that you wish to make. Provide the feature you would like to see, why you need it, and how it will work. Discuss your ideas transparently and get community feedback before proceeding.
Significant Changes that you wish to contribute to the project should be discussed first in a GitHub issue that clearly outlines the changes and benefits of the feature.
Small Changes can directly be crafted and submitted to the GitHub Repository as a Pull Request.
Commit your changes:
git commit -m "Commit message"
git push
Then open Github interface and create pull request. Please follow guide from PR body template.
After pull request is created, it get a corresponding number, e.g. 123 (pr_number
).
Evacuator
uses towncrier
for changelog management.
To submit a change note about your PR, add a text file into the docs/changelog/next_release folder. It should contain an explanation of what applying this PR will change in the way end-users interact with the project. One sentence is usually enough but feel free to add as many details as you feel necessary for the users to understand what it means.
Use the past tense for the text in your fragment because, combined with others, it will be a part of the "news digest" telling the readers what changed in a specific version of the library since the previous version.
You should also use
reStructuredText syntax for highlighting code (inline or block),
linking parts of the docs or external sites.
If you wish to sign your change, feel free to add -- by
:user:`github-username`
at the end (replace github-username
with your own!).
Finally, name your file following the convention that Towncrier
understands: it should start with the number of an issue or a
PR followed by a dot, then add a patch type, like feature
,
doc
, misc
etc., and add .rst
as a suffix. If you
need to add more than one fragment, you may add an optional
sequence number (delimited with another period) between the type
and the suffix.
In general the name will follow <pr_number>.<category>.rst
pattern,
where the categories are:
feature
: Any new featurebugfix
: A bug fiximprovement
: An improvementdoc
: A change to the documentationdependency
: Dependency-related changesmisc
: Changes internal to the repo like CI, test and build changes
A pull request may have more than one of these components, for example a code change may introduce a new feature that deprecates an old feature, in which case two fragments should be added. It is not necessary to make a separate documentation fragment for documentation changes accompanying the relevant code changes.
Added a ``:github:user:`` role to Sphinx config -- by :github:user:`someuser`
Fixed behavior of ``WebDAV`` connector -- by :github:user:`someuser`
Added support of ``timeout`` in ``S3`` connector
-- by :github:user:`someuser`, :github:user:`anotheruser` and :github:user:`otheruser`
Tip
See pyproject.toml for all available categories
(tool.towncrier.type
).
Just add ci:skip-changelog
label to pull request.
Before making a release from the develop
branch, follow these steps:
- Checkout to
develop
branch and update it to the actual state
git checkout develop
git pull -p
- Backup
NEXT_RELEASE.rst
cp "docs/changelog/NEXT_RELEASE.rst" "docs/changelog/temp_NEXT_RELEASE.rst"
- Build the Release notes with Towncrier
VERSION=$(cat evacuator/VERSION)
towncrier build "--version=${VERSION}" --yes
- Change file with changelog to release version number
mv docs/changelog/NEXT_RELEASE.rst "docs/changelog/${VERSION}.rst"
- Remove content above the version number heading in the
${VERSION}.rst
file
awk '!/^.*towncrier release notes start/' "docs/changelog/${VERSION}.rst" > temp && mv temp "docs/changelog/${VERSION}.rst"
- Update Changelog Index
awk -v version=${VERSION} '/DRAFT/{print;print " " version;next}1' docs/changelog/index.rst > temp && mv temp docs/changelog/index.rst
- Restore
NEXT_RELEASE.rst
file from backup
mv "docs/changelog/temp_NEXT_RELEASE.rst" "docs/changelog/NEXT_RELEASE.rst"
- Commit and push changes to
develop
branch
git add .
git commit -m "Prepare for release ${VERSION}"
git push
- Merge
develop
branch tomaster
, WITHOUT squashing
git checkout master
git pull
git merge develop
git push
- Add git tag to the latest commit in
master
branch
git tag "$VERSION"
git push origin "$VERSION"
- Update version in
develop
branch after release:
git checkout develop
NEXT_VERSION=$(echo "$VERSION" | awk -F. '/[0-9]+\./{$NF++;print}' OFS=.)
echo "$NEXT_VERSION" > evacuator/VERSION
git add .
git commit -m "Bump version"
git push