Implement sample build on push to samples repo

[guardrex]

We'll need to get approval for this and have the docs management set it up. Enabling it myself ended up generating an internal policy violation.

#242

Resolved! 🎉

[guardrex]

@hakenr ... Made it here for work on building samples.

I'd prefer ...... I think 🤔 ...... to set up the builds on a per-sample push basis and not restore and rebuild all of them for any given push to one sample. I'm new to many Action concepts. It seems like it would require one Action YAML file per sample. Like this ...

https://github.com/dotnet/blazor-samples/blob/main/.github/workflows/validate-90-bwa.yml

... because it looks like the push path must be set in on:. I'll dig a bit more into conditional statements that might be placed in the job steps to control which command(s) are executed.

Also curious why you had separate restore and build steps in your script? Why not just build, given that it restores first?

WRT which SDK to grab, I thought that the latest could build all prior versions. Did you set up your script with the SDK matching the app's release version to avoid any kind of EOL scenario for a prior release?

[guardrex]

Yeah ... I think conditionals (if: github.XXX == 'YYY') will permit checking the path to where the push took place. I'll see if I can knock up the correct statement ... using their fairly rough documentation! 🙈😆.

[hakenr]

Also curious why you had separate restore and build steps in your script? Why not just build, given that it restores first?

Not sure. It was most likely taken from a GitHub Action template (or created by some GitHub wizard).

GPT-4o says it's a recommended approach and provides a few reasons - mainly related to maintainability, discoverability, and those "software craftsmanship" aspects.

[guardrex]

Right ... I see. I think just a straight build would be fine.

AI ... not my favorite source of information. 😆

I'm looking now on how one might control the steps of a job based on a path conditional. I haven't found it yet, but I really have a hard time with the GH docs. This is about the third time that I went looking for some seemingly simple use case information and couldn't find it. I know a guy who should be able to help if I can't track down the information that I'm seeking.

[hakenr]

WRT which SDK to grab, I thought that the latest could build all prior versions. Did you set up your script with the SDK matching the app's release version to avoid any kind of EOL scenario for a prior release?

I think the "latest SDK" approach could work well. It's "good enough" to catch serious build-time errors and "simple enough" to maintain. However, there's a chance that the latest SDK might compile newer constructs that weren't available in older versions or include fixes that could make the build behave differently compared to the original version.

[guardrex]

Very well. AFAIK, it should be ok. When this is set up and tested, I think we'll see fairly fast if things are going to 💥 using the 9.0 SDK to build the 3.1 samples here.

WRT controlling the job steps paths, I'll wire up https://github.com/dorny/paths-filter. I should then be able to control individual sample builds by push paths. I'll work on implementing that approach now to see if it will work.

[guardrex]

Yes, this approach will work well to only build the sample(s) pushed ...

https://github.com/dotnet/blazor-samples/blob/main/.github/workflows/validate-samples.yml

Next, I'll add in the paths for the other samples.