-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Simplify repetitive YAML of 'PublishBuildArtifacts' using default values #7101
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,7 +11,7 @@ | |
"author": "Microsoft Corporation", | ||
"version": { | ||
"Major": 1, | ||
"Minor": 133, | ||
"Minor": 135, | ||
"Patch": 0 | ||
}, | ||
"demands": [], | ||
|
@@ -21,15 +21,15 @@ | |
"name": "PathtoPublish", | ||
"type": "filePath", | ||
"label": "Path to publish", | ||
"defaultValue": "", | ||
"defaultValue": "$(Build.ArtifactStagingDirectory)", | ||
"required": true, | ||
"helpMarkDown": "The folder or file path to publish. This can be a fully-qualified path or a path relative to the root of the repository. Wildcards are not supported. [Variables](https://go.microsoft.com/fwlink/?LinkID=550988) are supported. Example: $(Build.ArtifactStagingDirectory)" | ||
}, | ||
{ | ||
"name": "ArtifactName", | ||
"type": "string", | ||
"label": "Artifact name", | ||
"defaultValue": "", | ||
"defaultValue": "artifact", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the designer templates I spot checked, the artifact name is defaulted to "drop". Can we standardize on that? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @hashtagchris thanks for checking that! Yes, let's use the same name in both places. Somehow, "drop" is vague to me. Internally we refer to "build drops", but is that old school, and what's common elsewhere? Since they're called "build artifacts," I thought "artifact" would be better. But maybe I'm wrong. Is "drop" more meaningful to people? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think "drop" was used to signify build drop. We should check if changing this will have an undesirable impact on the UI or elsewhere There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we're going to change the default, what do you think of "build"? App Center has this: I think having the default name "artifact" may make it harder to communicate that there are multiple artifact categories and that you can publish multiple build artifacts. Here's what you would get with our .Net Desktop template: Also the artifact name is used in file paths for unc shares and downloads, and 8 characters puts us closer to the 260 character file limit. Admittedly having "build" in those file paths may be a bit odd: \myshare\builds\20180401.01\build\Release\ConsoleApp1.exe There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agree "artifact" seems overloaded and will create confusion. "drop" is a fairly common term to indicate a build output. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for your research and thoughts on this. I'll leave it as drop unless @jerickmsft has an opinion on it. |
||
"required": true, | ||
"helpMarkDown": "The name of the artifact to create in the publish location" | ||
}, | ||
|
@@ -38,7 +38,7 @@ | |
"aliases": [ "publishLocation" ], | ||
"type": "pickList", | ||
"label": "Artifact publish location", | ||
"defaultValue": "", | ||
"defaultValue": "Container", | ||
"required": true, | ||
"helpMarkDown": "Choose whether to store the artifact in Visual Studio Team Services/TFS, or to copy it to a file share that must be accessible from the build agent.", | ||
"options": { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not all tasks will output to the artifact staging directory, so having a default that may not work is not a good idea. It is better to leave it empty since default of $(System.workingdirectory) is more likely to work for most tasks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll propose it's okay to default this value for when artifacts are in the Build.ArtifactStagingDirectory folder. Then, people only have to change it if they depart from the prescribed pattern. ArchiveFiles does this by defaulting its rootFolderOrFile input to
$(Build.BinariesDirectory)
. When it comes to artifacts, the following tasks default to Build.ArtifactStagingDirectory: DotNetCoreCLI, DownloadBuildArtifacts, AppCenterTest, HelmDeploy, NuGetCommand, and DownloadPackage. So this change would make PublishBuildArtifacts more in harmony with those too. Also, our build templates already default the PublishBuildArtifacts task to use this value.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want people to be selective with what they publish to the service, I think it would be good to either make$(Build.ArtifactStagingDirectory) the default path, or to add match patterns to this task. $ (Build.ArtifactStagingDirectory) is better if the default match pattern would be
**\*
.FWIW, if you publish $(Build.ArtifactStagingDirectory) without copying any files to it, your build succeeds with a warning from the agent:
##[warning]Directory 'D:\a\1\a' is empty. Nothing will be added to build artifact 'drop'.