Favor project-specific build scripts over top-level script #29918
Conversation
captainsafia
force-pushed
the
safia/fix-build-scripts
branch
from
10fd34d
to
aa7771b
Compare
Pilchie
added
the
area-infrastructure
captainsafia
force-pushed
the
safia/fix-build-scripts
branch
3 times, most recently
from
a1fb62a
to
011ac76
Compare
captainsafia
changed the title
captainsafia
force-pushed
the
safia/fix-build-scripts
branch
from
011ac76
to
4b5e8e1
Compare
captainsafia
force-pushed
the
safia/fix-build-scripts
branch
from
4b5e8e1
to
686a2ea
Compare
captainsafia
requested review from
halter73,
jkotalik,
JunTaoLuo and
Tratcher
as code owners
There was a problem hiding this comment.
Need build.* scripts in
- src/Configuration.KeyPerFile/
- src./DefaultBuilder/
- src/Features/
- src/FileProviders/
- src/Html/
- src/HttpClientFactory/
- src/Installers/Debian
- src/Installers/Rpm
- src/Logging.AzureAppServices/
- src/ObjectPool/
- src/Shared/
- src/Testing/
- src/WebEncoders/
captainsafia
requested review from
javiercn,
pranavkm and
a team
as code owners
|
Should we have a (non helix) test that just runs all of these build scripts to ensure they work in some way (exit code 0?) |
We have a pipeline executing .azure\pipelines\devBuild.yml but removed or disabled it because nobody was paying attention. If you have suggestions to extend that YAML and make the pipeline useful to the team, fine. But, that said, the scripts are mostly 💯% identical and I can't see how they would fail without something almost intentionally messed up e.g. lots of weird references to bin/ or obj/ folders without project references. |
Right because its a separate pipeline, while if we had a normal azdo test that ran every one of these scripts as part of ci builds, it wouldn't be ignorable and would guarantee these scripts always work (and are reasonably not flaky) |
Main concerns there are the effort required to clean the repo after each script runs (because project references mean they're highly intertwined) and the overall time it would take. Using Helix might be easier though it may be difficult to get right initially e.g. does the Helix SDK support this❔ |
I guess helix would work pretty well as a new test that basically verified contributor workflow, could just exercise the getting started instructions / clone the repro, install preqs, do a build, and also do a clean and try each individual sub build script. Would be easier to just do that on the existing build machines as they are already setup, but there's decent value in ensuring that our repo always works from a clean state |
docs/BuildFromSource.md
Outdated
| @@ -224,6 +224,8 @@ code . | |||
|
|
|||
| When developing in VS Code, you'll need to use the `build.cmd` or `build.sh` scripts in order to build the project. You can learn more about the command line options available, check out [the section below](using-dotnet-on-command-line-in-this-repo). | |||
|
|
|||
| After navigating to the parent directory of the desired project, you can run the build script for that individual project. | |||
There was a problem hiding this comment.
Does "parent directory" here mean something like "closest ancestor directory that contains a build.cmd/build.sh file"? Many of the .csproj files don't have a build script in their immediate parent directory.
There was a problem hiding this comment.
Correct -- I've added some more text/samples here to explain the relationship between the build scripts and the project modified.
…pnetcore#29918) * Remove top-level build scripts in favor of project specific scripts * Add more build scripts and move top-level to eng * Fix path in Powershell script * Update BuildDirectory for CI jobs * Fix paths in restore scripts and jobs * Address feedback from peer review * Fix references to Html.Abstractions * Update baseline files with new project * Fix a few more broken links * !fixup! Correct Build.props and regen project references * Update docs and fix public api modification check Co-authored-by: Doug Bunting <[email protected]> Commit migrated from dotnet/aspnetcore@0801cea403b2
Unfortunately, it doesn't look like we can totally move the
build.sh/build.cmdscripts out of the top-level directory and intoengsince various parts of Arcade rely on build scripts being in the top-level. But this PR:Addresses #27631