Contributing to ansible-pylibssh¶
ansible-pylibssh project exists solely to allow Ansible connection plugins to use libssh SSH implementation by importing it in Python-land. At the moment we don’t accept any contributions, nor feature requests that are unrelated to this goal.
But if you want to contribute a bug fix or send a pull-request improving our CI, testing and packaging, we will gladly review it.
In order to contribute, you’ll need to:
Fork the repository.
Create a branch, push your changes there. Don’t forget to include news files for the changelog.
Send it to us as a PR.
Iterate on your PR, incorporating the requested improvements and participating in the discussions.
- Testing Guide
Running the tests suite locally
We use Sphinx to generate our docs website. You can trigger the process locally by executing:
$ tox -e build-docs
It is also integrated with Read The Docs that builds and publishes each commit to the main branch and generates live docs previews for each pull request.
The sources of the Sphinx documents use reStructuredText as a de-facto standard. But in order to make contributing docs more beginner-friendly, we’ve integrated MyST parser allowing us to also accept new documents written in an extended version of Markdown that supports using Sphinx directives and roles. Read the docs to learn more on how to use it.
Adding change notes with your PRs¶
It is very important to maintain a log for news of how updating to the new version of the software will affect end-users. This is why we enforce collection of the change fragment files in pull requests as per Towncrier philosophy.
The idea is that when somebody makes a change, they must record the bits that would affect end-users only including information that would be useful to them. Then, when the maintainers publish a new release, they’ll automatically use these records to compose a change log for the respective version. It is important to understand that including unnecessary low-level implementation related details generates noise that is not particularly useful to the end-users most of the time. And so such details should be recorded in the Git history rather than a changelog.
Alright! So how do I add a news fragment?¶
To submit a change note about your PR, add a text file into the
docs/changelog-fragments/ 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
RST syntax for highlighting code (inline or block), linking
parts of the docs or external sites.
At the end, sign your change note by adding
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
bugfix 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.
Examples for changelog entries adding to your Pull Requests¶
Added a ``:user:`` role to Sphinx config -- by :user:`webknjaz`
Added the support for keyboard-authentication method -- by :user:`Qalthos`
Fixed flaky SEGFAULTs in ``pylibsshext.channel.Channel.exec_command()`` calls -- by :user:`ganeshrn`
pyproject.toml for all available categories