Contributing to Flyte#
Thank you for taking the time to contribute to Flyte! Please read our Code of Conduct before contributing 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. You can find them here.
Appetizer for every repo: 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.
Note
To open a pull request, follow this guide.
Example PR for your reference: GitHub PR. A couple of checks are introduced to help maintain the robustness of the project.
To get through DCO, sign off on every commit (Reference)
To improve code coverage, write unit tests to test your code
Make sure all the tests pass. If you face any issues, please let us know
On a side note, format your Go code with golangci-lint
followed by goimports
(use make lint
and make goimports
), and Python code with black
and isort
(use make fmt
).
If make targets are not available, you can manually format the code.
Refer to Effective Go, Black, and Isort for full coding standards.
As you become more involved with the project you may be able to be added as a contributor to the repos you’re working on, but there is a medium term effort to move all development to forks ✨.
📃 Documentation#
Flyte uses Sphinx for documentation. protoc-gen-doc
is used to generate the documentation from .proto
files.
Sphinx spans multiple repositories under flyteorg. It uses reStructured Text (rst) files to store the documentation content. For API- and code-related content, it extracts docstrings from the code files.
To get started, refer to the reStructuredText reference.
For minor edits that don’t require a local setup, you can edit the GitHub page in the documentation to propose improvements.
The edit option can be found at the bottom of a page, as shown below.

Intersphinx#
Intersphinx can generate automatic links to the documentation of objects in other projects.
To establish a reference to any other documentation from Flyte or within it, use Intersphinx.
To do so, create an intersphinx_mapping
in the conf.py
file which should be present in the respective docs
repository.
For example, rsts
is the docs repository for the flyte
repo.
For example:
intersphinx_mapping = {
"python": ("https://docs.python.org/3", None),
"flytekit": ("https://flyte.readthedocs.io/projects/flytekit/en/master/", None),
}
The key refers to the name used to refer to the file (while referencing the documentation), and the URL denotes the precise location.
Here is an example using :std:doc
:
Direct reference
Task: :std:doc:`generated/flytekit.task`
Output:
Task: flytekit.task
Custom name
:std:doc:`Using custom words <generated/flytekit.task>`
Output:
You can cross-reference multiple Python objects. Check out this section to learn more.
For instance, task decorator in flytekit uses the func
role.
Link to flytekit code :py:func:`flytekit:flytekit.task`
Output:
Link to flytekit code flytekit.task()
Here are a couple more examples.
:py:mod:`Module <python:typing>`
:py:class:`Class <python:typing.Type>`
:py:data:`Data <python:typing.Callable>`
:py:func:`Function <python:typing.cast>`
:py:meth:`Method <python:pprint.PrettyPrinter.format>`
Output:
🧱 Component Reference#
To understand how the below components interact with each other, refer to Understand the lifecycle of a workflow

The dependency graph between various flyte.org repos#
flyte
#
Purpose: Deployment, Documentation, and Issues |
Languages: Kustomize & RST |
Note
For the flyte
repo, run the following command in the repo’s root to generate documentation locally.
make -C rsts html
flyteidl
#
Purpose: Flyte workflow specification is in protocol buffers which forms the core of Flyte |
Language: Protobuf |
Guidelines: Refer to the README |
flytepropeller
#
Purpose: Kubernetes-native operator |
Language: Go |
Guidelines:
|
flyteadmin
#
Purpose: Control Plane |
Language: Go |
Guidelines:
|
flytekit
#
Purpose: Python SDK & Tools |
Language: Python |
Guidelines: Refer to the Flytekit Contribution Guide |
flyteconsole
#
datacatalog
#
Purpose: Manage Input & Output Artifacts |
Language: Go |
flyteplugins
#
Purpose: Flyte Plugins |
Language: Go |
Guidelines:
|
flytestdlib
#
Purpose: Standard Library for Shared Components |
Language: Go |
flytesnacks
#
Purpose: Examples, Tips, and Tricks to use Flytekit SDKs |
Language: Python (In the future, Java examples will be added) |
Guidelines: Refer to the Flytesnacks Contribution Guide |
flytectl
#
Purpose: A standalone Flyte CLI |
Language: Go |
Guidelines: Refer to the FlyteCTL Contribution Guide |
🔮 Recommended Iteration Cycle#
As you may have read in other parts of the documentation, this repo contains go code as well that pulls in all the backend components (admin, propeller, data catalog, console) into one executable.
The Flyte team is also working on migrating the core backend repositories into one repo, some time in 2023. For the time being, you can still contribute by making changes to the individual repos, and then bringing them into this flyte
repo. This setup works well for backend golang development, but is not tested for flyteconsole
development. That development cycle will look a bit different. This setup here will allow you to run the Flyte binary from your IDE, hitting any breakpoints you may have, but will connect you to all the other resources of the demo environment (like postgres, rds).
Setup#
Dev Mode Cluster#
To launch the dependencies, teardown any old sandboxes you may have, and then run
``flytectl demo start --dev``
This will run the demo environment but without Flyte itself. This makes it so that you the developer can run it later, on your host machine.
Set up Flyte configuration#
Copy the file
flyte-single-binary-local.yaml
to~/.flyte/local-dev-config.yaml
Replace instances of
$HOME
with the real path of your home directory.
Cluster Resources#
You’ll notice one of the entries in the config is cluster_resources.templatePath
. In this folder you should put the templates for the cluster resource controller to use. For now, it’s okay to just start with the namespace one. Create a file called ~/.flyte/cluster-resource-templates/00_namespace.yaml
with the following
.. literalinclude:: ../../charts/flyte-binary/eks-production.yaml
:lines: 81-85
Pull Console Artifacts#
Run the following command from the base folder of this repo to pull in the static assets for Flyteconsole
make cmd/single/dist
Build & Iterate#
Update using go get github.com/flyteorg/<component>&gitsha
to bring in the code of the component you’re testing. From there, you can run
POD_NAMESPACE=flyte go run -tags console cmd/main.go start --config ~/.flyte/local-dev-config.yaml
The POD_NAMESPACE
environment is required for the webhook to work. Of course you can create a build target in your IDE with the same effective command as well.
After it’s running, you should still be able to go to localhost:30080/console
to see Flyte but now hosted by your host computer. It relies on a Docker host mapping to get the correct IP for your local host.
🐞 File an Issue#
GitHub Issues is used for issue tracking. The following are available issue types that you could use for filing an issue.
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.