@akashveramd is attempting to deploy a commit to the Meta Open Source Team on Vercel.

A member of the Team first needs to authorize it.

Unfortunately, rolling this would be hard work because all callers of linux_job_v2 would need to pass id-token: write permission explicitly. This is a popular workflow with a long list of callers https://github.com/search?type=code&q=org%3Apytorch+linux_job_v2.yml, so I'm not sure this is the approach we want to take

Hi @malfet, it seems you approved the request. But I closed the PR thinking I have found a work around where we don't need to change linux_job_v2.yaml. However, I think I was wrong about it. Having aws-setup as a part of linux_job_v2.yaml looks like an only option. Can you please re-approve the changes?

@akashveramd I didn't approve it, I've requested changes as it's break all existing CI workflows

@akashveramd I didn't approve it, I've requested changes as it's break all existing CI workflows

@malfet: I think those failures are happening because the workflow is running from a forked PR and the permission to gha_workflow_s3_and_ecr_read_only is not granted to it. I had a similar issue in my torchtitan PR where I was trying to do aws authentication inside the workflow. @huydhn pointed to this issue in the slack channel discussion.

As a short-term workaround, Huy gave me write permission to the pytorch/torchtitan repo and I migrated my torchtitan PR directly inside pytorch/torchtitan, instead of my fork. With that aws issues disappeared.

@huydhn do you mind validating those then?

Um, no, my comment here #7115 (comment) still stands. This workflow does have id-token: write which is needed by OIDC. If we add it here to linux_job_v2, we need to do the same for all callers of the workflow, which are many https://github.com/search?type=code&q=org%3Apytorch+linux_job_v2.yml. So, it's better to not use this for ROCm jobs, or create a new reusable workflow for ROCm

You might have fixed it on torchtitan, but other users of linux_job_v2 would need to do the same on their end

Um, no, my comment here #7115 (comment) still stands. This workflow does have id-token: write which is needed by OIDC. If we add it here to linux_job_v2, we need to do the same for all callers of the workflow, which are many https://github.com/search?type=code&q=org%3Apytorch+linux_job_v2.yml. So, it's better to not use this for ROCm jobs, or create a new reusable workflow for ROCm

You might have fixed it on torchtitan, but other users of linux_job_v2 would need to do the same on their end

@huydhn: Instead of modifying this workflow, I can create a new reusable workflow for ROCm with aws authentication. Something like linux_job_v2_rocm.yml

@huydhn, @malfet: Created a new reusable workflow linux_job_v2_rocm.yml and rolled back changes to linux_job_v2.yml.

@huydhn: Instead of modifying this workflow, I can create a new reusable workflow for ROCm with aws authentication. Something like linux_job_v2_rocm.yml

Yes, that sounds reasonable

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Preview	Updated (UTC)
torchci	Ignored	Preview	Oct 3, 2025 10:46pm

A suggestion here is to add a test workflow like https://github.com/pytorch/test-infra/blob/main/.github/workflows/test_linux_job_v2.yml for this new one. It's hard to avoid failures otherwise

A suggestion here is to add a test workflow like https://github.com/pytorch/test-infra/blob/main/.github/workflows/test_linux_job_v2.yml for this new one. It's hard to avoid failures otherwise

@huydhn: Sorry, are you suggesting that I should create something like .github/workflows/test_linux_job_v2_rocm.yml and that will run for linux_job_v2_rocm.yml? Similar to how .github/workflows/test_linux_job_v2.yml runs for linux_job_v2.yml.

@huydhn: Sorry, are you suggesting that I should create something like .github/workflows/test_linux_job_v2_rocm.yml and that will run for linux_job_v2_rocm.yml? Similar to how .github/workflows/test_linux_job_v2.yml runs for linux_job_v2.yml.

Yup, exactly, you can call this new workflows rocm_job.yml and test_rocm_job.yml IMO. linux_job_v2_rocm.yml and test_linux_job_v2_rocm.yml is too lengthy :)