ansible-sshd/contributing.md
Jakub Jelen d48e898148
docs: Fix spelling issues + fix reported issues (#274)
* README: Fix double-the in documentation

* README: Consistently referer to the role name and not to repository name

* README: Improve wording

* Fix more typos

* ci: Add GH action to check for spelling mistakes
2024-01-29 17:55:43 +00:00

2.8 KiB

Contributing to ansible-sshd

Where to start

The first place to go is Contribute. This has all of the common information that all role developers need:

  • Role structure and layout
  • Development tools - How to run tests and checks
  • Ansible recommended practices
  • Basic git and github information
  • How to create git commits and submit pull requests

Bugs and needed implementations are listed on Github Issues. Issues labeled with help wanted are likely to be suitable for new contributors!

Code is managed on Github, using Pull Requests.

Creating a release

You must use automation to create releases consistently. The process of creating a release is the following:

  1. Clone ansible-sshd, ensure that you have a remote for your fork configured and checkout a new branch to use for a release PR:

    git clone git@github.com:willshersystems/ansible-sshd.git
    git remote add <your_gh_username> git@github.com:<your_gh_username>/ansible-sshd.git
    git checkout -b new-ver
    
  2. Get the linux-system-roles/auto-maintenance/role-make-version-changelog.sh script:

    wget https://raw.githubusercontent.com/linux-system-roles/auto-maintenance/main/role-make-version-changelog.sh
    
  3. Run the linux-system-roles/auto-maintenance/role-make-version-changelog.sh script:

    sh role-make-version-changelog.sh
    

    This script creates updates CHANGELOG.md with a summary of pull requests added since the previous release and with automatically identified new version based on the PR types. It also optionally updates .README.html with changes to README.md made since the previous release.

    To learn more about available script options, see role-make-version-changelog.sh documentation.

  4. Verify that the script added a commit for new release by running git log.

  5. Push the changes to your fork and create a PR.

These are all the manual steps that you must do to initiate a new release. After the PR is reviewed and merged, i.e. after changes are made to CHANGELOG.md, the changelog_to_tag.yml workflow triggers and creates tag and release.