Repository navigation
Publish the OPC UA module stagings - #34
Merged
Merged
Conversation
alexadereyko
force-pushed
the
jira/TBBAS-3304-stage-opcua
branch
from
August 19, 2026 14:51
1e63ca5 to
af94c36
Compare
alexadereyko
marked this pull request as ready for review
August 27, 2026 08:56
alexadereyko
force-pushed
the
jira/TBBAS-3304-stage-opcua
branch
from
September 7, 2026 16:54
3783a4e to
ed9a2bf
Compare
The stage workflow pulls the core staging matching each job, builds the modules against it and publishes them to ghcr. CPack packs the module runtime into a TGZ named by opendaq-cmake-utils, the same way core names its packages.
Without the component scope the package also carries the MSVC runtime that InstallRequiredSystemLibraries installs, which core already ships.
The staging index of a core commit is tagged with its sha, so opendaq_ref -- already the ref this repository builds against -- is resolved to one and the pull asks for that, instead of whatever latest points at. The job list, what each job pulls and where the stagings are published are literal, so the workflow shows them. The job computes the two values that cannot be written down: the commit and the channel the branch publishes to.
Stagings exist only from openDAQ/openDAQ#1265 on, so this is the one core commit the pull can resolve today.
A staging matrix is seven runners, and most of the merges between two runs produce nothing a consumer asks for. workflow_dispatch covers what cannot wait for the schedule.
Temporary: until the workflow reaches main, workflow_dispatch is not offered, so pushing is the only way to run it outside a pull request.
A pull request is checked out as its merge commit, so what it publishes is tagged with a sha that lives in no branch and cannot be pinned or cloned.
The staging pulled so far was published from a pull request, so its sha was a merge commit -- in the registry, but in no branch, so the source build could not check it out.
The pinned core carried a packaging bug that only shows when the SDK is built as a subproject, which is what the source path of this repository does.
The rule is the same in every repository, and the staging build had its own copy of it. Reading the pinned ref is all that is left here, and it is a line.
A repository owns the packages it publishes, so it is the one that can delete them. Only the nightly channel is listed: a channel that is never cleaned is how a release is kept.
Grouping the runs cancels a pending one when a third arrives, which leaves a commit unpublished and nothing republishes it. Publishing weekly and on demand, runs do not overlap enough for the group to buy anything.
The push trigger was there to run the workflow before it reached main, where workflow_dispatch becomes available.
The referenced openDAQ-CI branches and the cmake utils ci/staging branch were deleted once their PRs merged, so neither the workflow calls nor FetchContent resolved any more. The workflows now point at the branch carrying the pinned job configs, and the job names follow: manylinux builds with gcc-toolset-14, macOS with the Xcode-pinned Apple clang 17 or 21. The utils are pinned to v1.0.3, the release cut from that merge.
The pinned configs merged and are tagged v3.
The core staging was pulled from the test channel, left from before core published to dev and stable. A release branch now builds against the stable core, any other branch against dev.
arm64 starts at macOS 11.0, so 10.15 was raised silently in the build but recorded as is: the staging metadata named os.version 10.15 for binaries that need 11.0.
Core stages ARM Linux on the manylinux baseline for the ARM wheels, and those need the modules on the same glibc baseline.
alexadereyko
force-pushed
the
jira/TBBAS-3304-stage-opcua
branch
from
September 22, 2026 10:25
d1309ca to
b8b7bd7
Compare
A pull request that pins core to a commit without a staging would only fail at the next weekly publish. The check resolves the channel the same way the publish does and looks the pinned tag up there.
v1 ran its whole default matrix, and v3 renamed the jobs after their pinned compilers. The job list, the 32-bit lane and its i386 packages follow LT, less OpenSSL, which the OPC UA modules don't link.
v1.1.1 suppresses the GCC stringop-overflow false positive that fails the aarch64 release build on date::detail::read.
alexadereyko
force-pushed
the
jira/TBBAS-3304-stage-opcua
branch
from
September 24, 2026 10:17
ab2a52a to
71f7bb1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The stage workflow pulls the core staging matching each job, builds the modules against it and publishes them to ghcr.
CPack packs the module runtime into a TGZ named by opendaq-cmake-utils, the same way core names its packages.