Skip to content

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

Closed
dagood opened this issue Sep 4, 2018 · 4 comments · Fixed by dotnet/installer#10972
Closed

Improve official build tarball file name #747

dagood opened this issue Sep 4, 2018 · 4 comments · Fixed by dotnet/installer#10972
Assignees
Labels
area-build Improvements in source-build's own build process area-release Release tasks or related issues

Comments

@dagood
Copy link
Member

dagood commented Sep 4, 2018

With this line, we get names like tarball_1987062.tar.gz:

tarballName: tarball_$(Build.BuildId)

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).

@dagood dagood added area-build Improvements in source-build's own build process area-release Release tasks or related issues labels Sep 4, 2018
@omajid
Copy link
Member

omajid commented Sep 4, 2018

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 (2.1.3, not 2.1). A common convention in various projects is to call their release tarball as NAME-VERSION.(tar.gz|zip). So something like dotnet-3.2.9.tar.gz for a final release.

@dagood
Copy link
Member Author

dagood commented Sep 4, 2018

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.

/cc @dleeapho @dseefeld @crummel

@dseefeld
Copy link
Contributor

dseefeld commented Sep 6, 2018

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.

@MichaelSimons
Copy link
Member

This will be addressed with the ArPow feature work. The agreed upon file name will be dotnet-sdk-source-<version>.tar.gz. This name is in alignment with the other .NET artifacts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-build Improvements in source-build's own build process area-release Release tasks or related issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants