Publish the LT streaming module stagings - #17
Draft
alexadereyko wants to merge 15 commits into
Draft
Conversation
alexadereyko
force-pushed
the
jira/TBBAS-3302-stage-lt-modern
branch
2 times, most recently
from
August 18, 2026 13:47
d01b569 to
3a24827
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.
The commit the pin named was staged before the branch was rebased; this one is what core publishes now.
alexadereyko
force-pushed
the
jira/TBBAS-3302-stage-lt-modern
branch
from
August 19, 2026 14:51
3fc777e to
ac40446
Compare
The TLS channel needs OpenSSL, and the ubuntu containers, manylinux and 32-bit Windows do not ship it. Same recipe as the downstream CI: the package manager where there is one, vcpkg on Windows.
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.
opendaq_ref is what this repository builds against, and a merge that names a core without a staging breaks every build after it. The check asks the registry for that one staging, in the channel the branch the change lands on builds against.
The downstream check ran on the v2 tag while the staging build already calls the branch, so the two exercised different matrices.
The rule is the same in every repository, and the staging build had its own copy of it next to the gate's. Reading the pinned ref is all that is left here, and it is a line.
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
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.