Skip to main content

​
Welcome contributors

Contributions to container are welcomed and encouraged. Whether you’re fixing bugs, adding features, improving documentation, or helping with testing, your contributions help make container better for everyone.

​
Main contributing guide

For comprehensive contribution guidelines, please see the main contributing guide in the Containerization project. This guide covers:
  • Code of conduct
  • How to submit issues
  • Pull request process
  • Coding standards
  • License information
  • Community guidelines
The container project shares contribution guidelines with the Containerization project to maintain consistency across the ecosystem.

​
Getting started

Before contributing, make sure you:
1

Set up your development environment

Follow the building from source guide to set up your development environment with all required dependencies.
2

Understand the architecture

Read the architecture documentation to understand how container works and how components interact.
3

Run tests

Verify your environment by running the test suite to ensure everything is working correctly.
4

Install pre-commit hook

Set up the pre-commit hook to ensure code quality:
make pre-commit

​
Areas for contribution

With the initial release of container, many common containerization features remain to be implemented. Consider contributing in these areas:

​
Feature development

  • New container runtime features
  • Enhanced networking capabilities
  • Additional image management features
  • Performance optimizations
  • macOS integration improvements

​
Bug fixes

  • Security vulnerabilities
  • Stability issues
  • Performance problems
  • Edge case handling

​
Documentation

  • Improving existing documentation
  • Adding examples and tutorials
  • Clarifying technical explanations
  • Documenting undocumented features

​
Testing

  • Writing new tests
  • Improving test coverage
  • Adding integration tests
  • Performance benchmarking
Consider contributing new features and bug fixes to both container and the Containerization projects.

​
Development workflow

A typical contribution workflow:
1

Fork and clone

Fork the repository and clone it to your local machine.
2

Create a branch

Create a feature branch for your changes:
git checkout -b feature/my-new-feature
3

Make changes

Implement your changes, following the project’s coding standards.
4

Test thoroughly

Run the full test suite:
make all test integration
5

Commit with proper formatting

The pre-commit hook will ensure proper formatting and license headers:
git commit -m "Add new feature"
6

Push and create PR

Push your branch and create a pull request with a clear description of your changes.

​
Code quality standards

​
Formatting

The pre-commit hook automatically checks:
  • Code formatting
  • License headers
  • Basic style issues
Install it with: 
make pre-commit

​
Testing requirements

All contributions should:
  • Include appropriate tests
  • Pass existing tests
  • Maintain or improve code coverage
  • Pass integration tests
Pull requests that break existing tests or significantly reduce code coverage may not be accepted.

​
Documentation requirements

Code changes should include:
  • Updated API documentation
  • Comments for complex logic
  • Updates to relevant documentation pages
  • Examples where appropriate

​
Building with local dependencies

If your contribution requires changes to related projects:

​
Containerization changes

See the building guide for instructions on linking to a local Containerization repository.

​
Builder changes

See the building guide for instructions on testing builder changes.

​
Debugging your changes

Use the debugging guide to:
  • Attach debuggers to XPC helpers
  • Debug service initialization
  • Troubleshoot integration issues
  • Analyze runtime behavior
The CONTAINER_DEBUG_LAUNCHD_LABEL environment variable is invaluable for debugging service-level changes.

​
Project status

The container project is currently under active development:
  • Stability is only guaranteed within patch versions (e.g., between 0.1.1 and 0.1.2)
  • Minor version releases may include breaking changes until 1.0.0
  • The API and architecture may evolve significantly
Keep this in mind when planning contributions, especially those that involve API changes or architectural modifications.

​
Getting help

If you need help with your contribution: Contributions may involve these related projects: Make sure to review contribution guidelines for these projects if your changes span multiple repositories.

Build docs developers (and LLMs) love

Get started for freeTalk to us