Skip to content

Latest commit

 

History

History
243 lines (164 loc) · 5.29 KB

CONTRIBUTING.md

File metadata and controls

243 lines (164 loc) · 5.29 KB

Contributing to Runpod Public Endpoints n8n Node

Thank you for your interest in contributing! This document provides guidelines for contributing to the Runpod Public Endpoints n8n Community Node.

🚀 Getting Started

Prerequisites

  • Node.js 18+
  • npm or yarn
  • Git
  • n8n instance for testing

Development Setup

  1. Fork and Clone

    git clone https://github.com/runpod/n8n-nodes.git
cd n8n-nodes

  2. Install Dependencies

    npm install

  3. Build the Node

    npm run build

  4. Link for Development

    npm link

  5. Start n8n

    n8n dev

📝 Code Style

  • Use TypeScript for all new code
  • Follow existing naming conventions
  • Add JSDoc comments for public methods
  • Use meaningful variable and function names

🧪 Testing

Manual Testing

  1. Test all operation types (text, image, video, audio)
  2. Test error scenarios (invalid API key, malformed JSON)
  3. Test async operations with polling
  4. Test model dropdown filtering

Test Checklist

  • Text generation works
  • Image generation works
  • Video generation works
  • Audio processing works
  • Status checking works
  • Error handling works
  • Model dropdown filters correctly
  • Credentials work properly

🐛 Reporting Bugs

When reporting bugs, please include:

  1. Environment

    • n8n version
    • Node.js version
    • Operating system

  2. Steps to Reproduce

    • Clear, numbered steps
    • Expected vs actual behavior

  3. Error Messages

    • Full error logs
    • Screenshots if applicable

  4. Additional Context

    • Workflow configuration
    • API key status (without sharing the key)

💡 Feature Requests

When suggesting features:

  1. Describe the Problem

    • What use case does this solve?
    • How does it improve the user experience?

  2. Propose a Solution

    • Clear description of the feature
    • Mockups or examples if applicable

  3. Consider Alternatives

    • Are there existing workarounds?
    • How does this fit with the existing API?

🔄 Pull Request Process

  1. Create a Branch

    git checkout -b feature/your-feature-name

  2. Make Your Changes

    • Write clean, documented code
    • Add tests if applicable
    • Update documentation as needed
    • Ensure code passes linting and type checking

  3. Test Thoroughly

    npm run lint
npm run build
    • Test all affected functionality
    • Ensure no regressions

  4. Submit PR

    • Clear title and description
    • Link to related issues
    • Include screenshots for UI changes

📋 PR Checklist

  • Code follows project style guidelines
  • Self-review completed
  • Build passes: npm run build
  • Lint passes: npm run lint
  • Documentation updated
  • No breaking changes (or clearly documented)
  • All CI checks pass

🏷️ Release Process

We use Changesets to manage versioning and releases.

1. Create a Changeset

When you make changes that should be released, create a changeset:

npm run changeset -- add

This will prompt you to:

  • Choose the type of change:
    • patch: Bug fixes, small improvements
    • minor: New features, backwards compatible changes
    • major: Breaking changes
  • Write a summary of the changes

2. Commit and Push

git add .
git commit -m "feat: your feature description"
git push origin feature/your-feature-name

3. Create Pull Request

Create a PR to merge your changes into main. The changeset file will be included in your PR.

4. Automated Release

Once your PR is merged to main:

  1. Version PR Created: Changesets action creates a PR with:

    • Updated version numbers in package.json
    • Generated CHANGELOG.md entries
    • Consumed changeset files

  2. Publish Release: When the version PR is merged:

    • Package is built: npm run build
    • Published to npm with OIDC/trusted publishers
    • GitHub Release created automatically

Release Types

  • Patch (1.0.0 → 1.0.1): Bug fixes, documentation updates
  • Minor (1.0.0 → 1.1.0): New features, improvements
  • Major (1.0.0 → 2.0.0): Breaking changes

Manual Release (Emergency Only)

If you need to publish manually without the workflow:

# Update versions and generate changelog
npm run changeset:version

# Build
npm run build

# Publish to npm
npm run changeset:publish

Best Practices

  1. Always create changesets for user-facing changes
  2. Write clear changeset summaries - they become changelog entries
  3. Test thoroughly before creating PRs
  4. Follow semantic versioning when choosing change types
  5. Keep PRs focused - one feature/fix per PR

📞 Getting Help

  • GitHub Issues: For bugs and feature requests
  • GitHub Discussions: For questions and general discussion
  • Runpod Support: For API-related questions

📄 License

By contributing, you agree that your contributions will be licensed under the MIT License.

Thank you for contributing! 🎉