Contributing code

Thank you for taking the time to contribute to Flyte!

Here are some guidelines for you to follow, which will make your first and follow-up contributions easier.

TL;DR: Find the repo-specific contribution guidelines in the Component Reference section.

💻 Becoming a contributor

An issue tagged with good first issue is the best place to start for first-time contributors.

Fork and clone the concerned repository. Create a new branch on your fork and make the required changes. Create a pull request once your work is ready for review.

Example PR for your reference: GitHub PR. Several checks are introduced to help maintain the robustness of the project:

1. To get through DCO, sign off on every commit ( Reference).
2. To improve code coverage, write unit tests to test your code.
3. Make sure all the tests pass. If you face any issues, please let us know in the #contribute channel.
4. Format your Go code with golangci-lint followed by goimports (use make lint and make goimports).
5. Format your Python code with black and isort (use make fmt).
6. If make targets are not available, you can manually format the code.

As you become more involved with the project, you may be able to be added as a committer to the repos you’re working on. Check out the Flyte Contributor Ladder to learn more.

Before submitting your PR

We strongly encourage you to add one of these labels to your Pull Request:

• added: For new features.
• changed: For changes in existing functionality.
• deprecated: For soon-to-be-removed features.
• removed: For features being removed.
• fixed: For any bug fixes.
• security: In case of vulnerabilities.

This is helpful to build human-readable release notes. Learn more.

🐞 File an issue

We use GitHub Issues for issue tracking. The following issue types are available for filing an issue:

• Plugin Request
• Bug Report
• Documentation Bug/Update Request
• Core Feature Request
• Flytectl Feature Request
• Housekeeping
• UI Feature Request

If none of the above fit your requirements, file a blank issue. Also, add relevant labels to your issue. For example, if you are filing a Flytekit plugin request, add the flytekit label.

For feedback at any point in the contribution process, feel free to reach out to us on Slack.

🧱 Component Reference

To understand how the below components interact with each other, refer to Understand the lifecycle of a workflow.

flyte

Repo	flyte
Purpose	Deployment, Documentation, and Issues
Languages	RST

flyteidl

Repo	flyteidl
Purpose	Flyte workflow specification is in protocol buffers which forms the core of Flyte
Language	Protobuf
Guidelines	Refer to the README

flytepropeller

Repo	flytepropeller | Code Reference
Purpose	Kubernetes-native operator
Language	Go
Guidelines
	- Check for Makefile in the root repo
	- Run the following commands:
	- make generate
	- make test_unit
	- make lint
	- To compile, run make compile

flyteadmin

Repo	flyteadmin | Code Reference
Purpose	Control Plane
Language	Go
Guidelines
	- Check for Makefile in the root repo
	- If the service code has to be tested, run it locally:
	- make compile
	- make server
	- To seed data locally:
	- make compile
	- make seed_projects
	- make migrate
	- To run integration tests locally:
	- make integration
	- (or to run in containerized dockernetes): make k8s_integration

flytekit

Repo	flytekit
Purpose	Python SDK & Tools
Language	Python
Guidelines	Refer to the Flytekit Contribution Guide

flyteconsole

Repo	flyteconsole
Purpose	Admin Console
Language	Typescript
Guidelines	Refer to the README

datacatalog

Repo	datacatalog | Code Reference
Purpose	Manage Input & Output Artifacts
Language	Go

flyteplugins

Repo	flyteplugins | Code Reference
Purpose	Flyte Plugins
Language	Go
Guidelines
	- Check for Makefile in the root repo
	- Run the following commands:
	- make generate
	- make test_unit
	- make lint

flytestdlib

Repo	flytestdlib
Purpose	Standard Library for Shared Components
Language	Go

flytectl

Repo	flytectl
Purpose	A standalone Flyte CLI
Language	Go
Guidelines	Refer to the FlyteCTL Contribution Guide