Contributing to Fleet Intelligence Agent

View as Markdown

Issue Tracking

Please start all enhancement, bugfix, or change requests by opening a GitHub issue. Include clear reproduction steps, expected behavior, and environment details. Issues will be triaged and prioritized by maintainers before code review.

Development

Prerequisites

  • Go 1.26.6+ (see go.mod)
  • Make
  • golangci-lint (optional locally, required in CI)

First clone the source code from GitHub

git clone https://github.com/dsx-ai-factory/fleet-intelligence-agent.git

Build Fleet Intelligence Agent from source

cd fleetint
make all           # or: make fleetint
./bin/fleetint -h

Common development targets:

make fmt   # format code with gofmt
make lint  # run linting (golangci-lint if available)
make test  # run unit tests with coverage

Testing

We highly recommend writing tests for new features or bug fixes and ensuring all tests pass before submitting a PR.

To run tests locally:

make test

Documentation

The agent documentation lives in docs/ and is published to docs.nvidia.com/fleet-intel/agent. Published docs are built from release tags — editing docs/*.md on your branch is all that is needed; the CI publish workflow handles versioning automatically when a release is cut.

Prerequisites

Install the Fern CLI (requires Node.js 18+):

npm install -g fern-api

Previewing HEAD docs (your working changes)

To preview the current state of docs/ as it would appear in the docs site:

fern docs dev

This uses the navigation: block in fern/docs.yml to serve your local docs/*.md files directly. No version selector is shown — this mode is intentional for quickly reviewing in-progress edits.

Previewing with the version selector

To preview with the full version selector (current and previous versions as they appear on the published site), first fetch the versioned content from release tags:

python3 scripts/docs-fetch-versions.py --patch-fern-docs
fern docs dev

The --patch-fern-docs flag temporarily replaces the navigation: block in fern/docs.yml with a versioned versions: block. When you are done previewing, restore the file:

git checkout fern/docs.yml

Note: fern/versions/ is gitignored. Its contents are generated locally by the script and by CI at publish time — never commit them.

Adding or removing a doc page

  1. Add or remove the .md file under docs/.
  2. Update the navigation: block in fern/docs.yml to match.
  3. If the filename is non-obvious, add a title entry to TITLE_MAP in scripts/docs-fetch-versions.py.
  4. Run fern check to validate the configuration before opening a PR.

Developer Certificate of Origin (DCO)

Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or
(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or
(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.
(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

How to Sign Your Work

To sign your work and agree to the DCO, you must add a sign-off to every git commit. This is done by using the -s flag when committing:

git commit -s -m "Your commit message"

This will append a line that looks like:

Signed-off-by: Your Name <your.email@example.com>

You must use your real name and a valid email address. Anonymous contributions or contributions under pseudonyms are not accepted.

If you forget to add the sign-off to a commit, you can amend it:

git commit --amend --signoff

For more information about the DCO, see: https://developercertificate.org/

Pull Request Process

  1. Fork the Repository: Create a personal fork of the Fleet Intelligence Agent repository on GitHub.

  2. Create a Branch from Main: Create a new branch for your changes from the main branch:

    git checkout -b your-feature-name

  3. Make Your Changes: Implement your changes following the coding standards outlined below.

  4. Test Your Changes: Ensure all tests pass and add new tests for your changes if applicable.

  5. Squash Commits: Before finalizing your pull request, squash multiple commits into a single, clean commit:

    # Interactive rebase to squash commits (replace N with number of commits)
    git rebase -i HEAD~N
    # Or squash all commits in your feature branch
    git rebase -i main

    Choose “squash” (or “s”) for commits you want to combine.

  6. Sign-off Final Commit: Make sure your final squashed commit is signed off according to the DCO requirements:

    # If you need to add sign-off to your final commit
    git commit --amend --signoff

    Your final commit should have:

    • A properly formatted commit message (see format below)
    • Proper DCO sign-off
    • A single logical change

    Commit Message Format:

    feat: add GPU temperature monitoring
    - Implement temperature threshold checking
    - Add Prometheus metrics for temperature alerts
    - Include unit tests for temperature validation
    Signed-off-by: Your Name <your.email@example.com>

    Format: type: brief description

    • Type: feat, fix, docs, test, refactor, perf, chore
    • Description: Clear, imperative mood summary (e.g., “Add feature” not “Added feature”)

  7. Submit Pull Request: Create a pull request against the main branch with:

    • A clear title in the same default format as commits, for example feat: add GPU temperature monitoring
    • A description with a concise summary of the change
    • If there is a related GitHub issue, reference it in the PR body using a format like [#123]
    • Summary of changes made
    • Any breaking changes highlighted

  8. Code Review: Address any feedback from maintainers during the review process.

Coding Standards

Ensure your code is clean, readable, and well-commented. We use the following tools and guidelines:

Go Code Standards

  • Follow standard Go conventions and idioms
  • Use gofmt for code formatting (run make fmt)
  • Use golangci-lint for linting (run make lint)
  • Import grouping: third-party imports must be separated from local imports. goimports is configured with local-prefixes: github.com/dsx-ai-factory/fleet-intelligence-agent in .golangci.yml. If imports are regrouped incorrectly, run make fmt and make lint.

To run linting locally:

make lint

General Guidelines

  • Write clear, descriptive commit messages
  • Keep commits focused and atomic
  • Sign off every commit with git commit -s
  • Add comments for non-trivial logic
  • Update documentation when adding or changing features
  • Ensure backward compatibility when possible