-
Notifications
You must be signed in to change notification settings - Fork 136
Improve official build tarball file name #747
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
Comments
Are you mostly concerned about the regular daily builds? or final public releases (eg, .NET Core 2.1.3)? Or both? If you are producing release-style tarballs, I would strongly suggest a including the actual full version ( |
I think both. Ideally the continuous/dailyish build for each commit produces a tarball that's fit to release if there's a corresponding Microsoft release. Thanks for the input. I realized we could also use VSTS logging commands to "export" the value for the build def to use from the package version that we actually produce in source-build, rather than auto-updating. We could also try to make the build simply more flexible and not care about the exact name. I think it's reasonable to go after that convention. |
Note: Names should use the same pattern that is used for existing assets. i.e. dotnet-<component>-<version>.ext This will be relevant when we split runtime and SDK as well. |
This will be addressed with the ArPow feature work. The agreed upon file name will be |
Uh oh!
There was an error while loading. Please reload this page.
With this line, we get names like
tarball_1987062.tar.gz
:source-build/.vsts.pipelines/phases/ci-linux.yml
Line 35 in bb2b2d1
We should figure out something better (and still maintainable).
Maybe
dotnet-source-build-{last part of branch}-{7 chars of commit hash}-{date}
, to be complete? E.g. ending up like:dotnet-source-build-2.1-abc4567-2018-09-04.tar.gz
.dotnet-source-build-2.1-abc4567-2018-09-04-smoke-test-prereqs.tar.gz
To include the full 2.1.3 (or 2.1.401) branding
we'd have to auto-update it from somewhere and have it checked in, which doesn't seem worth it(edit: see below, there are some other ways).2.1
should already be available as$(Build.SourceBranchName)
.The text was updated successfully, but these errors were encountered: