4fe6a5dc34
Move the slow test json to be in the pytorch/pytorch repo and make a job that will update it weekly. The job uses the same environment as the commit hash. It uses similar code to the hash updates, but the hash update contains a lot of code that is specific to the hash update, so I chose to pick out the parts that are relevant Remove references to the old file and set up testing to read from the new file instead The old update cadence was every day, the new one is every week The auto slow test infra + the lack of pinning between pytorch and test-infra makes it really hard to tell if a test started failing because of a change or because of the slow test json changing. While this can have benefits, like disable test issues being effective everywhere immediately, it can also be very confusing, especially since we don't have the same insight into slow tests like we do for disable issues. Example PR made: https://github.com/pytorch/pytorch/pull/132383 (with all the changes from this PR because it was working on top of this) We should just get rid of this at some point in favor of the slowTest decorator, but there are some tests that take 5+ minutes to run and I don't want to track them down right now Pull Request resolved: https://github.com/pytorch/pytorch/pull/132379 Approved by: https://github.com/huydhn |
||
|---|---|---|
| .. | ||
| anaconda-prune | ||
| promote | ||
| apply-release-changes.sh | ||
| cut-release-branch.sh | ||
| README.md | ||
| restore-backup.sh | ||
| tag-docker-images.sh | ||
PyTorch Release Scripts
These are a collection of scripts that are to be used for release activities.
NOTE: All scripts should do no actual work unless the
DRY_RUNenvironment variable is set todisabled. The basic idea being that there should be no potential to do anything dangerous unlessDRY_RUNis explicitly set todisabled.
Requirements to actually run these scripts
- AWS access to pytorch account
- Access to upload conda packages to the
pytorchconda channel - Access to the PyPI repositories
Promote
These are scripts related to promotion of release candidates to GA channels, these can actually be used to promote pytorch, libtorch, and related domain libraries.
Usage
Usage should be fairly straightforward and should actually require no extra variables if you are running from the correct git tags. (i.e. the GA tag to promote is currently checked out)
PACKAGE_TYPE and PACKAGE_NAME can be swapped out to promote other packages.
Promoting pytorch wheels
promote/s3_to_s3.sh
Promoting libtorch archives
PACKAGE_TYPE=libtorch PACKAGE_NAME=libtorch promote/s3_to_s3.sh
Promoting conda packages
promote/conda_to_conda.sh
Promoting wheels to PyPI
WARNING: These can only be run once and cannot be undone, run with caution
promote/wheel_to_pypi.sh
Restoring backups
All release candidates are currently backed up to s3://pytorch-backup/${TAG_NAME} and
can be restored to the test channels with the restore-backup.sh script.
Which backup to restore from is dictated by the RESTORE_FROM environment variable.
Usage
RESTORE_FROM=v1.5.0-rc5 ./restore-backup.sh