Skip to content

contributing.md

Latest commit

 

History

History
249 lines (182 loc) · 9.92 KB

contributing.md

File metadata and controls

249 lines (182 loc) · 9.92 KB
Raw

Contributing to the network Linux System Role

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.

GitHub CI testing using /citest

GitHub CI tests do not run automatically on pull requests. A role repository maintainer must start them by posting a /citest slash command as a pull request comment.

Run every available CI workflow:

/citest all

Run the linting and other lightweight checks:

/citest linters

Run the integration tests (QEMU/container and Testing Farm):

/citest integration

Run one or more selected workflows by separating their names with spaces:

/citest ansible-lint
/citest ansible-lint markdownlint

Post another /citest comment at any time to run another selection.

The table below lists each command, the check name shown in the pull request checks list, and what the test does. Matrix jobs produce one check per combination; those rows show the check name pattern.

Command Check name Description
/citest all All checks listed below Run every CI test available for this role
/citest linters Lint and lightweight checks Run ansible-lint, ansible-test, ansible-managed-var-comment, codespell, markdownlint, pr-title-lint, test_converting_readme, and codeql, python-unit-test, and shellcheck when those workflows exist
/citest integration QEMU/container and Testing Farm checks Run qemu-kvm-integration-tests and tft
/citest ansible-lint Ansible Lint / ansible_lint (<ansible-lint>, <ansible>, <python>) (pull_request) Lint Ansible content after converting the role to collection format
/citest ansible-managed-var-comment Check for ansible_managed variable use in comments / ansible_managed_var_comment (pull_request) Fail if ansible_managed is used in comments
/citest ansible-test Ansible Test / ansible_test (<ansible>, <python>) (pull_request) Run ansible-test sanity tests
/citest codespell Codespell / Check for spelling errors (pull_request) Check for spelling errors
/citest markdownlint Markdown Lint / markdownlint (pull_request) Lint Markdown files
/citest pr-title-lint PR Title Lint / commit-checks Check that the pull request title follows the required format
/citest qemu-kvm-integration-tests Test / scenario (<image>, <env>) (pull_request) Run role integration tests in QEMU VMs and containers
/citest test_converting_readme Test converting README.md to README.html / test_converting_readme (pull_request) Convert README.md to HTML
/citest tft <platform>|ansible-<version> Run integration tests in Testing Farm
/citest woke Woke / Detect non-inclusive language (pull_request) Detect non-inclusive language
/citest codeql CodeQL / Analyze (python) (pull_request) CodeQL security and quality analysis for Python
/citest python-unit-test Python Unit Tests / python (<python>, <os>) (pull_request) Run Python unit tests
/citest shellcheck ShellCheck / shellcheck (pull_request) Lint shell scripts

AI Coding Assistants

The .coderabbit.yaml configuration file in the repository root contains coding standards and requirements that can be used by AI coding assistants to help generate code that follows project conventions.

When a substantial portion of your code was generated by AI, add a comment with an attribution in-line to introduce the generated code, or at the top of the file under the SPDX comment (if any), like this:

# Assisted by <AI agent> using model(s) ModelA[, ModelB, ...]

For example:

# Assisted by SquirmingFerret using models CodeEchidna 7.1, SoftBadger 6

The git commit message/PR body should also contain an attribution like the following:

Assisted-by: <AI agent> using model(s) ModelA[, ModelB, ...]

Python Code

The Python code needs to be compatible with the Python versions supported by the role platform.

For example, see meta for the platforms supported by the role.

If the role provides Ansible modules (code in library/ or module_utils/) - these run on the managed node, and typically[1] use the default system python:

  • EL6 - python 2.6
  • EL7 - python 2.7 or python 3.6 in some cases
  • EL8 - python 3.6
  • EL9 - python 3.9

If the role provides some other sort of Ansible plugin such as a filter, test, etc. - these run on the control node and typically use whatever version of python that Ansible uses, which in many cases is not the system python, and may be a modularity release such as python311.

In general, it is a good idea to ensure the role python code works on all versions of python supported by tox-lsr from py36 on, and on py27 if the role supports EL7, and on py26 if the role supports EL6.[1]

[1] Advanced users may set ansible_python_interpreter to use a non-system python on the managed node, so it is a good idea to ensure your code has broad python version compatibility, and do not assume your code will only ever be run with the default system python.

Debugging network system role

When using the nm provider, NetworkManager create a checkpoint and reverts the changes on failures. This makes it hard to debug the error. To disable this, set the Ansible variable __network_debug_flags to include the value disable-checkpoints. Also tests clean up by default in case there are failures. They should be tagged as tests::cleanup and can be skipped. To use both, run the test playbooks like this:

ansible-playbook --skip-tags tests::cleanup \
    -e "__network_debug_flags=disable-checkpoints" \
    -i testhost, tests/playbooks/tests_802_1x.yml

NetworkManager Documentation

NM 1.0, it contains a full explanation about the NetworkManager API.

Integration tests with podman

  1. Create ~/.ansible/collections/ansible_collections/containers/podman/ if this directory does not exist and cd into this directory.

    mkdir -p ~/.ansible/collections/ansible_collections/containers/podman/
cd ~/.ansible/collections/ansible_collections/containers/podman/

  2. Clone the collection plugins for Ansible-Podman into the current directory.

    git clone https://github.com/containers/ansible-podman-collections.git .

  3. Change directory into the tests subdirectory.

    cd ~/network/tests

  4. Use podman with -d to run in the background (daemon). Use c7 because centos/systemd is centos7.

    podman run --name lsr-ci-c7 --rm --privileged \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
-d registry.centos.org/centos/systemd

  5. Use podman unshare first to run "podman mount" in root mode, use -vi to run ansible as inventory in verbose mode, use -c podman to use the podman connection plugin. NOTE: Some of the tests do not work with podman - see .github/run_test.sh for the list of tests that do not work.

    podman unshare
ansible-playbook -vi lsr-ci-c7, -c podman tests_provider_nm.yml

  6. NOTE that this leaves the container running in the background, to kill it:

    podman stop lsr-ci-c7
podman rm lsr-ci-c7

Running CI Tests Locally

Use tox-lsr with qemu

The latest version of tox-lsr supports qemu testing. https://github.com/linux-system-roles/tox-lsr#qemu-testing

Steps:

  1. If you are using RHEL or CentOS, enable the EPEL repository for your platform - https://docs.fedoraproject.org/en-US/epel/

  2. Use yum or dnf to install standard-test-roles-inventory-qemu

  3. Install tox

    • Use yum/dnf to install python3-tox - if that does not work, then use pip install --user tox, then make sure ~/.local/bin is in your $PATH

  4. Install tox-lsr https://github.com/linux-system-roles/tox-lsr#how-to-get-it

    pip install --user git+https://github.com/linux-system-roles/tox-lsr@main

  5. Download the config file to ~/.config/linux-system-roles.json from https://github.com/linux-system-roles/linux-system-roles.github.io/blob/main/download/linux-system-roles.json

  6. Assuming you are in a git clone of a role repo which has a tox.ini file - you can use e.g.

    tox -e qemu-ansible-core-2-20 -- --image-name centos-9 tests/tests_default.yml

There are many command line options and environment variables which can be used to control the behavior, and you can customize the testenv in tox.ini. See https://github.com/linux-system-roles/tox-lsr#qemu-testing

This method supports RHEL also - will download the latest image for a compose, and will set up the yum repos to point to internal composes.

See https://linux-system-roles.github.io/contribute.html for general development guidelines.