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

Use unstable version when publishing a stabilized build's outputs to blob storage #3763

Closed
dagood opened this issue Sep 12, 2019 · 5 comments

Comments

@dagood
Copy link
Member

dagood commented Sep 12, 2019

Note that this issue is talking about the build asset location, e.g.:

https://dotnetcli.blob.core.windows.net/dotnet/Runtime/3.1.0/dotnet-runtime-3.1.0-win-x64.exe

not the channels ("latest" links), which should remain the same:

https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/3.1/dotnet-runtime-latest-win-x64.exe

Core-SDK uses the build asset location to download bits, and having each stable build publish to the same location requires an overwrite, and dependency traceability is lost. There are also race conditions.

Core-Setup should always use an unstable version so that each build is available and no overwrites occur.

Note that Core-Setup needs to publish some package that has the unstable version, so that Core-SDK can use the version from that asset to find the virtual dir on dotnetcli. For example, Core-SDK needs to know the unstable and stable version to find this file:

https://dotnetcli.blob.core.windows.net/dotnet/Runtime/3.1.0-rc1.12345.1/dotnet-runtime-3.1.0-win-x64.exe

/cc @mmitche

@dagood
Copy link
Member Author

dagood commented Sep 16, 2019

@mmitche @JohnTortugo @riarenas, is this a considered a requirement for GA readiness?

/cc @dleeapho

@mmitche
Copy link
Member

mmitche commented Sep 16, 2019

Nope. We're good for GA. Just a matter of hygiene.

@dagood
Copy link
Member Author

dagood commented Sep 17, 2019

+cc @MichaelSimons, a future plan to use two types of version in the runtime download path to avoid overwrites. I think this will need changes in Docker download and version uptake. Example:

https://dotnetcli.blob.core.windows.net/dotnet/Runtime/3.1.0-rc1.12345.1/dotnet-runtime-3.1.0-win-x64.exe

No timeline for doing this yet.

@dagood
Copy link
Member Author

dagood commented Sep 18, 2019

Closing: I think this will be out of our control when moving to Arcade's blob publishing (https://github.com/dotnet/core-setup/issues/8285). It would be good for this to be supported by Arcade in some way. (Or superseded by a new feed feature?)

@dagood dagood closed this as completed Sep 18, 2019
@mmitche
Copy link
Member

mmitche commented Sep 18, 2019

@dagood Interestingly, it did do this for AspNetCore with arcade's publishing, something to keep in mind if your move in #3675 doesn't yield the expected results.

@msftgits msftgits transferred this issue from dotnet/core-setup Jan 30, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants