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>
## Description
Two related changes to how the 2.0 line is built and shipped.
### 1. Release-branch-only package publication
- `master` produces development previews only.
- Stable packages can only be built from a canonical
`release/<major>.<minor>` branch and are promoted manually from the
exact signed candidate artifact.
- Core packages use explicit `major.minor.patch` versions (`2.0.0`,
`2.0.1`, then `2.1.0`); git height never changes a stable package patch.
- XRegistry, WoT Connectivity, Vision, Robotics, Redundancy,
Positioning, OpenUSD, ISA95, AI, DI, the relevant MCP extensions, and
OpenUSD connector tools remain `-preview.N` while following the core
numeric version.
- nuget.org receives only non-`.Debug` package IDs; GitHub Packages
retains the complete signed Release/Debug candidate.
- `docs/ReleaseProcess.md` is a reproducible runbook for developers and
agents, with each step stating its completion evidence.
Promotion is source-bound and byte-checked: `release.yml` checks out
nothing until the candidate SHA is known, and
`assert-published-packages-match.ps1` proves that any version already on
a feed holds *this* candidate's content before `--skip-duplicate` is
allowed to skip it. Canonical release-branch naming is matched
case-sensitively with no leading zeroes, and `version.json`'s
`publicReleaseRefSpec`, both policy helpers and the copy `release.yml`
inlines are pinned to one expression by tests.
### 2. PR CI moved to GitHub-hosted runners
- `.github/workflows/buildandtest.yml` (**CI**) now owns pull-request
validation outright, covering the Windows Debug/Release net48 + net10.0
solution builds and fast tests that only Azure Pipelines ran, alongside
the existing Linux/macOS, all-target and NativeAOT legs. `build-and-test
summary` remains the stable required check name.
- `.github/workflows/nightly.yml` is a new **manual-only**
(`workflow_dispatch`) full-scope workflow covering the Azure nightly
workload: all solutions x seven target profiles x Debug/Release, the
net472/netstandard profiles, Windows + Linux NativeAOT, and the
long-running and durable tiers.
- Shared deterministic discovery/batching lives in
`.github/scripts/get-ci-matrix.ps1` with a local composite action, so
both entry points expand the same workload manifest instead of
duplicating a large embedded script.
- `azure-pipelines.yml` is set to `pr: none`.
- The standalone pump sample image workflow is folded into the
consolidated **Images CI** workflow, which now builds all ten images and
publishes an `images summary` rollup suitable as a required check.
## Related Issues
No related issue provided.
## Checklist
- [ ] I have signed the
[CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf)
and read the
[CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md)
doc.
- [x] I have added tests that prove my fix is effective or that my
feature works and increased code coverage.
- [x] I have added all necessary documentation.
- [x] I have verified that my changes do not introduce (new) build or
analyzer warnings.
- [ ] I ran **all** tests locally using the **UA.slnx** solution against
at least .net **framework** and .net **10**, and all passed.
- [ ] I fixed **all** failing and flaky tests in the CI pipelines and
**all** CodeQL warnings.
- [x] I have addressed **all** PR feedback received.
## Validation
- `Opc.Ua.Tools.Tests` full `net10.0` suite: **959 passed, 1 skipped, 0
failed**.
- Version/package-policy regression subset
(`PackageVersionPolicyTests`): **60 passed, 0 failed**.
- GitHub Actions **CI** run 35719807620: **149/149 jobs green** on
GitHub-hosted runners.
- Canonical release-branch rule verified against the pinned nbgv 3.7.115
by building throwaway branches: `release/2.0`, `release/0.9`,
`release/10.42` -> `PublicRelease=True`; `release/02.0`, `release/2.00`,
`Release/2.0` -> `False`.
- Package identity gate verified against a live nuget.org package:
served packages carry a repository `.signature.p7s`, so equality is
decided on content excluding that part. Re-signing and zip reordering
produce an identical digest; a one-byte content change does not.
- Synthetic Release-only, Debug-only, combined, preview, duplicate,
orphaned-symbol, mismatched-root and accidental-stable-family package
sets exercise the shared validator.
- Stable-release rehearsal in an isolated `release/2.0` clone:
`Opc.Ua.Di` packed as `2.0.0-preview.6` depending on stable Core
`2.0.0`; `Opc.Ua.Di.Client` likewise against stable Client `2.0.0`.
- All workflow YAML, `version.json`, the package-policy PowerShell
scripts and the internal release-runbook anchors parse.
## Known validation limits
- Full `UA.slnx` `net48` and `net10.0` local validation remains blocked
by pre-existing `NETSDK1005` and dependency-version failures in
unmodified fuzz/sample projects; the corresponding checklist items
intentionally stay open.
- The TRX-driven test verdict added for the intermittent at-exit host
stall is proven by `CiTestVerdictTests`; the stall itself has not
recurred since.
- `nightly.yml` has not yet been run against a full-scope Azure run for
tuple-level parity — see below.
## Operational follow-up
This remains a preparation PR targeting `master`. It does **not**
authorize a release.
Release sequence:
1. Merge this PR.
2. Create canonical `release/2.0`, advance `master` to
`2.1.0-preview.{height}`, and open a separate `2.0.0` version PR against
`release/2.0`.
3. Follow
[`docs/ReleaseProcess.md`](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/docs/ReleaseProcess.md)
for candidate dry-run, environment approval, promotion, tag/release
finalization, and next-patch preview setup.
CI migration steps still needing administrator access are tracked in
[`docs/DeveloperGuide.md#migration-status`](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/docs/DeveloperGuide.md#migration-status):
proving `nightly.yml` parity on a trusted SHA with the private fuzz
corpus provisioned, turning off definition 14's service-side PR
override, retiring the Azure full-scope schedules and push trigger, and
retiring the duplicate `azure-pipelines-preview.yml` publisher.
> **Before cutting `release/2.0`:** the `Release` ruleset requires the
Azure context for *every* `refs/heads/release/*`, but a new 2.x branch
inherits `pr: none`, so that context would never report and would block
every PR into the new line. Exclude the new ref from that ruleset, or
add a 2.x ruleset requiring `build-and-test summary`, as part of
creating the branch.
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Use Central Package Management
* Add Directory.Packages.props to solution files
* remove sourcelink version from common.props
* remove old entry from signlist
- Reduce memory allocations in JSON encoder by using stackalloc/ArrayPool
- Fix some new warnings in .NET9 code analyzers
- Fix fuzzing error in JsonDecoder
- do not use .NET9 libraries with .NET8 LTS builds #2931, #2940
- Bump langversion to 9 (max VS2019)
- Use official ASP.Net 2.3. libraries for .NET Framework (rel. Jan 15th)
- reduce EscapeString overhead in JSON encoder
- client monitored items: allocate queues only if needed
- replace SortedDictionary with Dictionary for perf reasons
- revert a change in padding and reduce a log level
- change macOS 11 ci builds to newer ones, macOS 11 is deprecated
- fix Opc.Ua.Client EventSource message numbering
- bump nerdgit to 3.6.139
- include .NET Standard 2.0 builds back in Nuget packages for client and server (complex type support requires netcoreapp2.1 which is end of life)
- include .NET Framework 4.7.2 as lowest supported .NET Framework platform
- move https client channel back to core library, as it requires only netstandard2.0 and has no other dependencies.
- Opc.Ua.Https is now only needed for a https server with kestrel.
- fix security warning for system.private.uri
- upload Quickstarts.Servers to the preview feed to allow use in the samples repo and avoid duplicate codebase
- complete build in Dockerfile, not in ci pipeline
- Use recommended build tasks for github actions
- build multiarch with linux/amd64,linux/arm64
- docker signing support with cosign (yet disabled)
* upload pipelineartifacts for release pipeline and sign the symbol packages
* enable deterministic builds for snupkg source debugging
* allow release builds to be in release/x.y.z
* do not rename assemblies for debug builds, to allow for mixing of release and debug packages. Otherwise build issues may occure when packages are mixed.
- use nerdbank.gitversioning to determine devops build version
- split nuget packages into new structure, one package per assembly to allow granular use of packages.
- also build .Debug versions
- back compat at least for a while, the old Opc.Ua packages reference also the new packages.
- devops produces preview builds for master
- preview builds are now signed, including nuget packages
- add license files for nuget packages, since licenseUrl is deprecated
- all changes for cloud based GDS
- build version of .net standard libs is now set in version.props, it may require updates for the official builds.
- add new stuff for v1.04 nodeset, e.g. QueryApplications Api
- gds.client/gds.server common dll changes to support a cloud based GDS.