Simplify repetitive YAML of 'PublishBuildArtifacts' using default values

[davidstaheli]

Each of our YAML templates has to repeat this common block:

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: '$(build.artifactStagingDirectory)'
    publishLocation: 'container'
    artifactName: 'artifact'

All of the above inputs are required. This PR simplifies them by adding default values. I don't think this is a change in behavior that calls for a major version bump. The resulting YAML looks like:

- task: PublishBuildArtifacts@1

[hashtagchris]

In the designer templates I spot checked, the artifact name is defaulted to "drop". Can we standardize on that?

[davidstaheli]

@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?

[madhurig]

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

[hashtagchris]

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

[madhurig]

Agree "artifact" seems overloaded and will create confusion. "drop" is a fairly common term to indicate a build output.

[davidstaheli]

Thanks for your research and thoughts on this. I'll leave it as drop unless @jerickmsft has an opinion on it.

[madhurig]

Left couple of comments

[madhurig]

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

[madhurig]

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.

[davidstaheli]

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.

[hashtagchris]

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

[hashtagchris]

BTW, @ericsciple recommended we use the major version bump as an opportunity to rename the task to PublishDropArtifact since it should work with release as well. See mortezag#2

[ericsciple]

@hashtagchris it matters less if you have a first class alias in yaml