Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate productVersion.txt with repo-specific name #48018

Merged

Conversation

michellemcdaniel
Copy link
Contributor

@michellemcdaniel michellemcdaniel commented Feb 8, 2021

In our efforts to unify the build access story using aka.ms links, we have found that there are certain files that share the same name in multiple different repositories, most importantly, productVersion.txt. As part of the work to move to aka.ms links, we will be flattening the short link paths, so rather than having a runtime-specific, aspnetcore-specific, etc. full path to the files generated by each of the repos, they will all go to the same short link location. This means that the path to productVersion.txt will collide in the aka.ms links (the backing locations are not changing and will be unaffected). To combat this, we will add a duplicate of each of the product repos productVersion.txt, renamed to indicate which product repo it came from, in this case runtime-productVersion.txt. The original will remane so that we do not break existing scenarios that do not use the aka.ms links.

Addresses dotnet/arcade#6862.

In our efforts to unify the build access story using aka.ms links, we have found that there are certain files that share the same name in multiple different repositories, most importantly, productVersion.txt. As part of the work to move to aka.ms links, we will be flattening the short link paths, so rather than having a runtime-specific, aspnetcore-specific, etc. full path to the files generated by each of the repos, they will all go to the same short link location. This means that the path to productVersion.txt will collide in the aka.ms links (the backing locations are not changing and will be unaffected). To combat this, we will add a duplicate of each of the product repos productVersion.txt, renamed to indicate which product repo it came from, in this case runtime-productVersion.txt. The original will remane so that we do not break existing scenarios that do not use the aka.ms links.
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@michellemcdaniel
Copy link
Contributor Author

@stephentoub is the OSX_x64 failure a known failure? I looked through some of the PRs submitted around the same time as mine and saw the same failure, but don't feel comfortable merging on red.

@stephentoub
Copy link
Member

is the OSX_x64 failure a known failure?

Probably. What's the failure? (It looks like the pipeline was restarted.)

@michellemcdaniel
Copy link
Contributor Author

I restarted it to see if it was transient. The original failure was:

/Users/runner/.dotnet/sdk/5.0.102/MSBuild.dll /nologo -maxcpucount /m -verbosity:m /v:minimal /bl:/Users/runner/work/1/s/artifacts/log/Release/ToolsetRestore.binlog /clp:Summary /clp:ErrorsOnly;NoSummary /nr:false /p:TreatWarningsAsErrors=true /p:ContinuousIntegrationBuild=true /p:__ToolsetLocationOutputFile=/Users/runner/work/1/s/artifacts/toolset/6.0.0-beta.21105.5.txt /t:__WriteToolsetLocation /warnaserror /Users/runner/work/1/s/artifacts/toolset/restore.proj
/Users/runner/work/1/s/artifacts/toolset/restore.proj : error : Unable to load the service index for source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json.
/Users/runner/work/1/s/artifacts/toolset/restore.proj : error : Unable to load the service index for source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json.
Build failed with exit code 1. Check errors above.

In Build CoreHost. Given that it has made it past that step, I think it was transient, but will wait for the re run leg to finish.

@michellemcdaniel michellemcdaniel merged commit 8054f4c into dotnet:master Feb 9, 2021
michellemcdaniel added a commit to michellemcdaniel/runtime that referenced this pull request Feb 9, 2021
In our efforts to unify the build access story using aka.ms links, we have found that there are certain files that share the same name in multiple different repositories, most importantly, productVersion.txt. As part of the work to move to aka.ms links, we will be flattening the short link paths, so rather than having a runtime-specific, aspnetcore-specific, etc. full path to the files generated by each of the repos, they will all go to the same short link location. This means that the path to productVersion.txt will collide in the aka.ms links (the backing locations are not changing and will be unaffected). To combat this, we will add a duplicate of each of the product repos productVersion.txt, renamed to indicate which product repo it came from, in this case runtime-productVersion.txt. The original will remane so that we do not break existing scenarios that do not use the aka.ms links.
michellemcdaniel added a commit to michellemcdaniel/runtime that referenced this pull request Feb 9, 2021
In our efforts to unify the build access story using aka.ms links, we have found that there are certain files that share the same name in multiple different repositories, most importantly, productVersion.txt. As part of the work to move to aka.ms links, we will be flattening the short link paths, so rather than having a runtime-specific, aspnetcore-specific, etc. full path to the files generated by each of the repos, they will all go to the same short link location. This means that the path to productVersion.txt will collide in the aka.ms links (the backing locations are not changing and will be unaffected). To combat this, we will add a duplicate of each of the product repos productVersion.txt, renamed to indicate which product repo it came from, in this case runtime-productVersion.txt. The original will remane so that we do not break existing scenarios that do not use the aka.ms links.
mmitche pushed a commit that referenced this pull request Feb 16, 2021
In our efforts to unify the build access story using aka.ms links, we have found that there are certain files that share the same name in multiple different repositories, most importantly, productVersion.txt. As part of the work to move to aka.ms links, we will be flattening the short link paths, so rather than having a runtime-specific, aspnetcore-specific, etc. full path to the files generated by each of the repos, they will all go to the same short link location. This means that the path to productVersion.txt will collide in the aka.ms links (the backing locations are not changing and will be unaffected). To combat this, we will add a duplicate of each of the product repos productVersion.txt, renamed to indicate which product repo it came from, in this case runtime-productVersion.txt. The original will remane so that we do not break existing scenarios that do not use the aka.ms links.
@ghost ghost locked as resolved and limited conversation to collaborators Mar 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants