mirror of
https://github.com/OPCFoundation/UA-.NETStandard.git
synced 2026-10-17 05:11:13 +08:00
romanett
a2539cb53d
Two unrelated CI faults in the GitHub Actions build/test matrix. ## Build steps fail after a successful compile — fixes #4458 `version.json` sets `cloudBuild.setVersionVariables`, so Nerdbank.GitVersioning's `SetCloudBuildVersionVars` target runs **once per project**, and on GitHub Actions the provider implements "set a variable" as an append to the file named by `$GITHUB_ENV`. The `Build` step is deliberately parallel across MSBuild nodes, so several nodes append to that one file concurrently, a line tears, and the runner rejects the fragment after the compile has already succeeded. Reproduced locally — one `GetBuildVersion` with `GITHUB_ACTIONS=true` appends three lines per project: ``` GitAssemblyInformationalVersion=2.0.337-preview+138086863b GitBuildVersion=2.0.337.4992 GitBuildVersionSimple=2.0.337 ``` A stray `7` is exactly what a torn `GitBuildVersion=2.0.3x7.yyyyy` leaves behind. After this change the same command writes **0 bytes**, and `Version`, `AssemblyVersion`, `FileVersion` and `PackageVersion` are unchanged (`2.0.337-preview.g138086863b`) — verified on both a sample project and `Opc.Ua.Sessions.Tests`. Nothing reads those three variables. Every workflow and pipeline that consumes version information runs `.azurepipelines/set-version.ps1` first, and `nbgv cloud -c -a` there writes the same `Git*` variables plus the `NBGV_*` set that `version.props` and `common.props` actually use — once, from a single process. This leaves that script as the only writer. Two notes against the fixes suggested in the issue: - `NerdbankGitVersioningSetCloudBuildVariables` does not exist in NBGV 3.10.94. The real gate is `'$(NBGV_SetCloudBuildVersionVars)' != 'false'`, so the suggested `/p:` would have been silently ignored. - Setting `cloudBuild.setVersionVariables: false` **would regress every version number**. The version height is the commit count since `version.json` last changed — `git rev-list --count 8d2402c99..HEAD` is exactly 337 — so editing that file at all resets the height. Measured: `nbgv cloud -c -a` with the flag flipped emits `NBGV_Version=2.0.0.4992` instead of `2.0.337.4992`. Hence an MSBuild property in `version.props` rather than a `version.json` edit. ## No dump when the test host dies natively — addresses #4447 (step 1) On [run 34158052372](https://github.com/OPCFoundation/UA-.NETStandard/actions/runs/34158052372/job/101853936251) the Sessions test host was lost to a glibc `double free or corruption (out)` and produced no dump at all, leaving native memory corruption in the security stack with no call stack. Neither dump path the job already configures covers that class of failure: - `--blame-crash-dump-type mini` goes through the runtime's `createdump`, which the runtime invokes only for crashes it handles itself; a raw `SIGABRT` out of glibc's malloc consistency check is not one of them. - `--blame-hang-dump-type mini` asks the test host to dump itself over the diagnostics socket, so it needs a runtime healthy enough to service the request. On that run it answered `Collect dump was enabled but no dump file was generated`. A kernel core depends on neither, so this adds three steps to the Linux legs: 1. **Enable native core dumps** — point `core_pattern` at `/tmp/coredumps` (outside the workspace, so `Upload test results` cannot sweep a multi-gigabyte file in by accident) and relax `kernel.yama.ptrace_scope` so a follow-up can also attach `gdb -p` or `dotnet-dump collect` to a wedged host. 2. **Raise `RLIMIT_CORE`** on the shell that launches the test host. The limit is inherited rather than global, so it cannot be raised from the step above. 3. **Stage Linux core dumps** — on failure, extract a `gdb` backtrace as text and always keep it; keep the compressed core only while it stays under 2 GiB. All three warn rather than fail: losing the ability to collect a core is not a reason to stop the tests from running. Healthy runs write nothing. **This makes the next occurrence diagnosable; the double free itself is not fixed here.** That is step 2 of the issue and it is explicitly gated on having a dump — guessing at a certificate-lifetime change in the security stack would invert straight into a leak. See the comment on #4447 for a correction to that issue's ECC hypothesis, which the raw job log does not support. ## Verification - YAML parses; both bash blocks pass `bash -n`; the pwsh block parses. - Staging script exercised through every branch: no cores, two cores, oversize drop, and `sudo`/`gdb` unavailable — each exits 0. - `version.props` change verified to emit nothing to `$GITHUB_ENV` while leaving the computed version identical. - CRLF line endings preserved in both files. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Marc Schier <marcschier@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: marcschier <11168470+marcschier@users.noreply.github.com>
66 lines
3.2 KiB
XML
66 lines
3.2 KiB
XML
<Project>
|
|
<ItemGroup Condition="$(NBGV_PublicRelease) != 'True' AND '$(CODEQL_RUNNER)' == '' AND '$(Dockerbuild)' != 'true'">
|
|
<!-- Note: Versions such as 3.6.146, where known working for 4 digit versioning -->
|
|
<PackageReference Include="Nerdbank.GitVersioning">
|
|
<PrivateAssets>all</PrivateAssets>
|
|
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
|
|
</PackageReference>
|
|
</ItemGroup>
|
|
<!-- set version manually in docker builds -->
|
|
<PropertyGroup Condition="'$(Dockerbuild)' == 'true'">
|
|
<GenerateAssemblyInfo>true</GenerateAssemblyInfo>
|
|
</PropertyGroup>
|
|
<!-- NBGV_ variables are only available in cloud build -->
|
|
<PropertyGroup Condition="'$(NBGV_PublicRelease)' == 'True'">
|
|
<!--
|
|
NBGV_Version is an assembly/build version and may contain a fourth
|
|
git-height component (for example 2.0.0.7). Packages instead use the
|
|
canonical SemVer value NBGV_NuGetPackageVersion (2.0.0): patch numbers
|
|
are explicit release decisions in version.json, never commit counts.
|
|
See docs/ReleaseProcess.md.
|
|
-->
|
|
<Version>$(NBGV_NuGetPackageVersion)</Version>
|
|
<VersionPrefix>$(NBGV_SimpleVersion)</VersionPrefix>
|
|
<VersionSuffix>$(NBGV_PrereleaseVersion)</VersionSuffix>
|
|
<AssemblyVersion>$(NBGV_SimpleVersion)</AssemblyVersion>
|
|
<FileVersion>$(NBGV_Version)</FileVersion>
|
|
<PackageVersion>$(NBGV_NuGetPackageVersion)</PackageVersion>
|
|
</PropertyGroup>
|
|
<!--
|
|
Do not let Nerdbank.GitVersioning publish cloud build variables from inside
|
|
MSBuild. Its SetCloudBuildVersionVars target runs once per project, and on
|
|
GitHub Actions the provider implements "set a variable" as an append to the
|
|
file named by $GITHUB_ENV. Builds here are deliberately parallel across
|
|
MSBuild nodes (see .github/scripts/run-dotnet-tests.ps1), so
|
|
several nodes append GitAssemblyInformationalVersion / GitBuildVersion /
|
|
GitBuildVersionSimple to that one file concurrently. Interleaved appends tear
|
|
a line, and the runner then rejects the leftover fragment after the compile
|
|
has already succeeded:
|
|
|
|
Build succeeded. 0 Error(s)
|
|
##[error]Unable to process file command 'env' successfully.
|
|
##[error]Invalid format '7'
|
|
|
|
('7' being the tail of a torn `GitBuildVersion=2.0.3x7.yyyyy`.) See issue
|
|
#4458.
|
|
|
|
Nothing reads these three variables: every workflow and pipeline that
|
|
consumes version information runs .azurepipelines/set-version.ps1 first, and
|
|
`nbgv cloud -c -a` there writes the same Git* variables plus the NBGV_* set
|
|
that version.props and common.props actually use - once, from a single
|
|
process, with no concurrency. This leaves that script as the only writer.
|
|
|
|
Note this is deliberately an MSBuild property rather than
|
|
cloudBuild.setVersionVariables in version.json: the version height is the
|
|
number of commits since version.json last changed, so editing that file at
|
|
all would reset the height to 0 and drop every produced version from
|
|
2.0.<height> to 2.0.0.
|
|
-->
|
|
<PropertyGroup>
|
|
<NBGV_SetCloudBuildVersionVars>false</NBGV_SetCloudBuildVersionVars>
|
|
</PropertyGroup>
|
|
<PropertyGroup>
|
|
<GitVersionBaseDirectory>$(MSBuildThisFileDirectory)</GitVersionBaseDirectory>
|
|
</PropertyGroup>
|
|
</Project>
|