@alexperovich PTAL

Why are we adding parameters to the template that is literally the parameters to the publish test results task? This feels like something that just makes it harder to reason about what the build is doing. IMO repos should just add a publish test results step themselves, its no more code than this is.

The difference is

publishTestResults:
  testResultsTitle: SomeTitle

vs

- task: PublishTestResults@2 
      displayName: Publish Test Results 
      inputs: 
        testResultsFormat: 'xUnit' 
        testResultsFiles: '*.xml'  
        searchFolder: '$(Build.SourcesDirectory)/artifacts/TestResults/$(_BuildConfig)'
        testResultsTitle: 'SomeTitle`

Your argument could be made for all templates.

For me the second is easier to grok than the contents of job.yml. Its just a bunch of characters that add some defaults to the parameters, but I had to parse out all of those if statements before I actually knew what it was doing. I don't have a super strong opinion either way though.

That's fair. The only reason I think this has merit to be supported is because we build in a lot of expectations about paths throughout Arcade and keeping that defined within the templates means that we can change those without breaking every repo that decided to custom implement some usage of a task...

searchFolder: '$(Build.SourcesDirectory)/artifacts/TestResults/$(_BuildConfig)

Is there a way to make the defaults more "defaulty", something like a: ${{ parameters.a or 'defaultA' }}?

Thanks to @zsd4yr, we can use VSO variables now:
https://github.com/dotnet/arcade/blob/master/eng/common/tools.ps1#L521-L523

Maybe it's time to add Artifacts.TestResults?

That's an interesting idea... It'd be great to get all of the paths out of the templates...

We should probably wait until #2038 is complete before rewriting this stuff.

@dsplaisted , I like the idea of using the Azure DevOps variables, but that does mean that you would have to remove "enablePublishTestResults" from your yaml and explicitly add the corresponding "PublishBuildArtifacts" step. Does that sound reasonable? If it does, then you can make that change now and then use the variable once it is available.

If possible, what I think is best is for the defaults to do the thing that is usually best, and be able to override that when necessary. So ideally by default in arcade you would get test results with meaningful titles without doing anything extra.

I don't need an ideal solution now though, so if I can figure out how to add my own publish step that sets the title, I'll be happy.

@chcosta Here's a PR to core-sdk which:

• Includes test results as part of build artifacts
• Sets test run title and build artifact filename to correspond to leg it came from

To do this we have to turn of the default arcade Azure Pipeline tasks. I think ideally this should eventually be the default for arcade, possibly with some ability to customize for common scenarios.

I presume that this is the PR you're referring to @dsplaisted

@chcosta Oops, yes :-)

@chcosta Any update? The default arcade logic doesn't give us helpful names, so we have to do this specifically in each of our repos.

dotnet/sdk#3221 (comment)
dotnet/installer#1609

#2038 hasn't quite landed yet. I'm going to close this PR as I think this isn't the right fix given the direction Arcade is heading.