Skip to content

Publish the LT streaming module stagings - #17

Draft
alexadereyko wants to merge 15 commits into
mainfrom
jira/TBBAS-3302-stage-lt-modern
Draft

Publish the LT streaming module stagings#17
alexadereyko wants to merge 15 commits into
mainfrom
jira/TBBAS-3302-stage-lt-modern

Conversation

@alexadereyko

Copy link
Copy Markdown
Contributor

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.

@alexadereyko
alexadereyko force-pushed the jira/TBBAS-3302-stage-lt-modern branch 2 times, most recently from d01b569 to 3a24827 Compare August 18, 2026 13:47
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
alexadereyko force-pushed the jira/TBBAS-3302-stage-lt-modern branch from 3fc777e to ac40446 Compare August 19, 2026 14:51
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant