Do we need to specify the binlog parameter here, or does the script always produce it to artifacts/log/$(buildConfiguration)/Build.binlog?

+1 for Eric's comment. Also, I don't like the idea of copying the build process manually into a parameter, that then runs PowerShell, that then runs the build. Instead, it should use our build template, sdk-build.yml, to do a build. That template can do a basic build with no tests (and will produce a binlog) as long as the right parameters are provided to the template.

We need a way to specify the binlog path, because there is no consistent buildConfiguration variable across all repos we can rely on. If we could unify what we call our configuration, then great! But that's a lot of repos.

As-is, the template has a default of artifacts/log/Debug/Build.binlog

@MiYanni okay, I've done some experimental redesign on the netsourceindex Arcade integration (using SDK as my test repo), and I'd appreciate some design feedback before I start trying to get it into Arcade.

Flow wise, it's not possible for netsourceindex's template to ingest sdk-build.yml, because both define jobs: (and jobs: cannot be nested within a job). So I've moved all the steps: from netsourceindex into a separate template which the existing job template imports (for backward compatibility) - and the new steps template can be imported by any existing (or new) job defined by the target repo as they see fit.

AS AN EXAMPLE, NOT A RECOMMENDATION I added it here on a not-yet-pushed-to-github internal copy of branch this. A build looks something like https://dev.azure.com/dnceng/internal/_build/results?buildId=2524323&view=logs&j=fa4e7bdb-0412-58a3-8823-7a72e2d8c65d&t=5cdd6b27-41ac-530b-e1af-013abe4bc807

I think adding a new managed-only Windows build leg would be best, but the template design allows that kind of decision to be made by the repo owner to best fit their needs.

If the idiom seems sound to you, then I can look at sending a PR to Arcade with the required prerequisite changes for adoption.

@directhex That looks much better as it doesn't require reconstitution of the build process by the repo. It being a drop-in template like this works much better, IMO. For our repo, if this process only needs to run once on the Windows job, you should do it like this:

1. Add a new variable named uploadSourceIndex under here and set it to true.
2. Add the same uploadSourceIndex variable under here and set it to false.
3. Since it looks like you want the build outputs included in the source index, the template should be added under here under that "Publish Logs" task.

- ${{ if eq(parameters.uploadSourceIndex, true) }}:
  - template: /eng/common/core-templates/steps/source-index-stage1-publish.yml
    parameters:
      binLogPath: artifacts\log\$(buildConfiguration)\Build.binlog

This way, it only runs once on the official Windows job and no where else.

+1 for Eric's comment. Also, I don't like the idea of copying the build process manually into a parameter, that then runs PowerShell, that then runs the build. Instead, it should use our build template, sdk-build.yml, to do a build. That template can do a basic build with no tests (and will produce a binlog) as long as the right parameters are provided to the template.