c6582f11cd
This extends the runner determinator to be able to opt-in to keywords to provide additional options when determining which systems to run jobs on. This enables us to support opt-in users to Amazon Linux 2023. This change creates a generic get_optin_feature() which hopefully will be useful to handle additional future features that we might want to experiment with. This change has kept backwards compatability with the existing issue userlist format and adds support for the comma-separated list of users in a backwards compatible way. The user list has the following rules: - Users are GitHub usernames with the @ prefix - If the first line is a "*" then all users will use the new runners - If the first line is a "!" then all users will use the old runners - Each user is also a comma-separated list of features/experiments to enable - A "#" prefix indicates the user is opted out of the new runners but is opting into features/experiments. Example user list: ``` @User1 @User2,amz2023 #@UserOptOutOfNewRunner,amz2023 ``` This closes pytorch/ci-infra#249. Pull Request resolved: https://github.com/pytorch/pytorch/pull/131792 Approved by: https://github.com/jeanschmidt, https://github.com/ZainRizvi |
||
|---|---|---|
| .. | ||
| amd | ||
| s390x-ci | ||
| build_triton_wheel.py | ||
| check_labels.py | ||
| cherry_pick.py | ||
| close_nonexistent_disable_issues.py | ||
| collect_ciflow_labels.py | ||
| comment_on_pr.py | ||
| convert_lintrunner_annotations_to_github.py | ||
| delete_old_branches.py | ||
| docathon-label-sync.py | ||
| drci_mocks.json.gz | ||
| ensure_actions_will_cancel.py | ||
| export_pytorch_labels.py | ||
| file_io_utils.py | ||
| filter_test_configs.py | ||
| generate_binary_build_matrix.py | ||
| generate_ci_workflows.py | ||
| generate_docker_release_matrix.py | ||
| generate_pytorch_version.py | ||
| get_aws_session_tokens.py | ||
| get_workflow_job_id.py | ||
| github_utils.py | ||
| gitutils.py | ||
| gql_mocks.json.gz | ||
| kill_active_ssh_sessions.ps1 | ||
| label_utils.py | ||
| lint_native_functions.py | ||
| lintrunner.sh | ||
| parse_ref.py | ||
| pr-sanity-check.sh | ||
| pytest_cache.py | ||
| pytest_caching_utils.py | ||
| README.md | ||
| report_git_status.sh | ||
| rockset_mocks.json.gz | ||
| runner_determinator.py | ||
| stop_runner_service.sh | ||
| sync_distributed_folder_prototype.sh | ||
| tag_docker_images_for_release.py | ||
| td_llm_indexer.sh | ||
| test_check_labels.py | ||
| test_filter_test_configs.py | ||
| test_gitutils.py | ||
| test_label_utils.py | ||
| test_pytest_caching_utils.py | ||
| test_trymerge.py | ||
| test_tryrebase.py | ||
| trymerge.py | ||
| trymerge_explainer.py | ||
| tryrebase.py | ||
| wait_for_ssh_to_drain.ps1 | ||
pytorch/.github
NOTE: This README contains information for the
.githubdirectory but cannot be located there because it will overwrite the repo README.
This directory contains workflows and scripts to support our CI infrastructure that runs on GitHub Actions.
Workflows
- Pull CI (
pull.yml) is run on PRs and on main. - Trunk CI (
trunk.yml) is run on trunk to validate incoming commits. Trunk jobs are usually more expensive to run so we do not run them on PRs unless specified. - Scheduled CI (
periodic.yml) is a subset of trunk CI that is run every few hours on main. - Binary CI is run to package binaries for distribution for all platforms.
Templates
Templates written in Jinja are located in the .github/templates directory
and used to generate workflow files for binary jobs found in the .github/workflows/ directory. These are also a
couple of utility templates used to discern common utilities that can be used amongst different templates.
(Re)Generating workflow files
You will need jinja2 in order to regenerate the workflow files which can be installed using:
pip install -r .github/requirements/regenerate-requirements.txt
Workflows can be generated / regenerated using the following command:
.github/regenerate.sh
Adding a new generated binary workflow
New generated binary workflows can be added in the .github/scripts/generate_ci_workflows.py script. You can reference
examples from that script in order to add the workflow to the stream that is relevant to what you particularly
care about.
Different parameters can be used to achieve different goals, i.e. running jobs on a cron, running only on trunk, etc.
ciflow (trunk)
The label ciflow/trunk can be used to run trunk only workflows. This is especially useful if trying to re-land a PR that was
reverted for failing a non-default workflow.
Infra
Currently most of our self hosted runners are hosted on AWS, for a comprehensive list of available runner types you
can reference .github/scale-config.yml.
Exceptions to AWS for self hosted:
- ROCM runners
Adding new runner types
New runner types can be added by committing changes to .github/scale-config.yml. Example: https://github.com/pytorch/pytorch/pull/70474
NOTE: New runner types can only be used once the changes to
.github/scale-config.ymlhave made their way into the default branch
Testing pytorch/builder changes
In order to test changes to the builder scripts:
- Specify your builder PR's branch and repo as
builder_repoandbuilder_branchin.github/templates/common.yml.j2. - Regenerate workflow files with
.github/regenerate.sh(see above). - Submit fake PR to PyTorch. If changing binaries build, add an appropriate label like
ciflow/binariesto trigger the builds.