Skip to content

Latest commit

 

History

History
167 lines (110 loc) · 6.86 KB

File metadata and controls

167 lines (110 loc) · 6.86 KB

NGC Terraform Provider Contribution Rules

Issue Tracking

Local Development Setup

Prerequisites
  • Go 1.25+ installed
  • golangci-lint v2.8.0+
  • gotestsum for test execution
  • Access to NGC API (for acceptance tests)
# Install required tools
go install gotest.tools/gotestsum@latest
Running Tests Locally
  1. Create your test configuration:

    cp test-config.env.example test-config.env
  2. Edit test-config.env with your NGC credentials and test environment settings:

    # Required: Your NGC API key
    NGC_API_KEY=your-api-key-here
    
    # Required: Your organization settings
    NGC_ORG=your-org-id
    NGC_TEAM=your-team-name
    # ... (see test-config.env.example for all options)

    ⚠️ Important: Never commit test-config.env - it contains sensitive credentials!

  3. Run tests:

    # Run unit tests (fast, no NGC API calls)
    make test
    
    # Run acceptance tests (requires NGC access, creates real resources)
    make testacc
    
    # Run linter
    make lint
Available Make Targets
Target Description
make test Run unit tests (no NGC API calls)
make testacc Run acceptance tests locally (reads from test-config.env)
make testacc-ci Run acceptance tests in CI (expects env vars set externally)
make lint Run golangci-lint
make generate_doc Generate provider documentation
make install Install the provider binary locally

Note: make testacc is for local development and reads configuration from test-config.env. make testacc-ci is used by GitHub Actions where environment variables are passed directly.

Environment Variables

For CI/CD, the following environment variables are used instead of the env file:

Variable Type Description
NGC_API_KEY Secret NGC API authentication key
NCA_ID Secret NCA identifier
AUTHORIZED_PARTY_1, AUTHORIZED_PARTY_2 Secret Authorized party IDs
NGC_ORG, NGC_TEAM, NGC_ENDPOINT Variable Organization config
CLUSTER_*, INSTANCE_TYPE, GPU_TYPE Variable Infrastructure config
HELM_*, CONTAINER_* Variable Deployment config
MODEL_* Variable Model test config

See test-config.env.example for the complete list.

Coding Guidelines

  • All source code contributions must passed the CI Jobs, including linter check, acceptance tests and/or unit tests.

    • Linter check will be executed with golangci-lint.
    • Acceptance tests will interact with NGC, such as creating, reading and destroying resources.
    • Unit tests test functionality without interact with NGC APIs, such as function tests.
  • Avoid introducing unnecessary complexity into existing code so that maintainability and readability are preserved.

  • Try to keep pull requests (PRs) as concise as possible:

    • Avoid committing commented-out code.
    • Wherever possible, each PR should address a single concern. If there are several otherwise-unrelated things that should be fixed to reach a desired endpoint, our recommendation is to open several PRs and indicate the dependencies in the description. The more complex the changes are in a single PR, the more time it will take to review those changes.
  • Write commit titles using imperative mood and these rules, and reference the Issue number corresponding to the PR. Following is the recommended format for commit texts:

#<Issue Number> - <Commit Title>

<Commit Body>
  • Ensure that the build log is clean, meaning no warnings or errors should be present.

  • Make sure that you can contribute your work to open source (no license and/or patent conflict is introduced by your code). You will need to sign your commit.

  • Thanks in advance for your patience as we review your contributions; we do appreciate them!

Pull Requests

Developer workflow for code contributions is as follows:

  1. Developers must first fork the upstream NGC Terraform Provider OSS repository.

  2. Git clone the forked repository and push changes to the personal fork.

  3. Once the code changes are staged on the fork and ready for review, a Pull Request (PR) can be requested to merge the changes from a branch of the fork into a selected branch of upstream.

Signing Your Work

  • We require that all contributors "sign-off" on their commits. This certifies that the contribution is your original work, or you have rights to submit it under the same license, or a compatible license.

    • Any contribution which contains commits that are not Signed-Off will not be accepted.
  • To sign off on a commit you simply use the --signoff (or -s) option when committing your changes:

    git commit -s -m "Add cool feature."

    This will append the following to your commit message:

    Signed-off-by: Your Name <your@email.com>
    
  • Full text of the DCO:

      Developer Certificate of Origin
      Version 1.1
    
      Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
      1 Letterman Drive
      Suite D4700
      San Francisco, CA, 94129
    
      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.