ci(publish): default the damlc component to 3.5.2 - #42
Merged
Conversation
The DAR publish pipeline declared damlc 3.4.11 while every archive it processes is newer: the vendored Splice DARs embed Sdk-Version 3.5.2, and all six daml.yaml files in this repo pin sdk-version: 3.5.2. The component is written into a generated dpm-workspace/daml.yaml alongside the dpm-codegen-cs OCI bundle, and it is the bundle -- not damlc -- that reads the DARs, so this was never miscompiling anything. It did leave the pipeline's stated contract untrue, and there is no way to correct it at release time: release.yaml passes no damlc_version to either DAR leg, so these defaults are the effective value on a tag push. The literal was duplicated across seven sites -- both triggers of each publish workflow, the shared reusable, and resolve-inputs.sh (the actual runtime fallback, plus its usage text). No 3.4.11 remains under .github/. 3.5.2 is the newest damlc that exists: it is the highest tag under components/damlc, and the 3.5, devnet, testnet and mainnet channel tags all resolve to it. daml-script, driven by the same input, tops out there too.
Contributor
Scala coverage
|
Contributor
C# coverage
|
Contributor
C# build matrix
|
Contributor
Scala build matrix
|
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
1 participant
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.
Defaults the DAR publish pipeline's
damlccomponent to 3.5.2.The mismatch
The pipeline declared
damlc3.4.11 while every archive it processes is newer — the vendored Splice DARs embedSdk-Version: 3.5.2, and all sixdaml.yamlfiles in this repo pinsdk-version: 3.5.2.To be precise about the blast radius: the component is written into a generated
dpm-workspace/daml.yaml(_publish-dar-packages.yaml:126-133) alongside thedpm-codegen-csOCI bundle, and it is the bundle — notdamlc— that reads the DARs. So this was never miscompiling anything. It did leave the pipeline's stated contract untrue, and it invites a real mismatch the first time something does read it.Why it has to land before the next tag
release.yamlcontains no reference todamlcat all: it callspublish-splice.yamlandpublish-daml-finance.yamlwithout adamlc_version, so each leg falls back to its own default. Those workflows then forward the value explicitly to the reusable, which means the reusable's default andresolve-inputs.sh's${DAMLC_VERSION_INPUT:-…}fallback are never consulted.The upshot is that these defaults are the effective value on a tag push, and there is no dispatch input that can override them. The last release ran with
DAMLC_VERSION: 3.4.11for exactly this reason.Seven sites, not five
The literal was duplicated beyond the two workflow inputs that advertise it — both the
workflow_callandworkflow_dispatchtriggers of each publish workflow carry it:publish-splice.yaml:19and:60publish-daml-finance.yaml:20and:62_publish-dar-packages.yaml:35— the shared reusable's own default.github/scripts/resolve-inputs.sh:43—EFFECTIVE_DAMLC="${DAMLC_VERSION_INPUT:-3.4.11}", the actual runtime fallback.github/scripts/resolve-inputs.sh:17— its usage textZero
3.4.11literals remain under.github/.Deliberately not touched
Four
3.4.11references elsewhere in the repo are unrelated or historical and stay as they are: twoCHANGELOG.mdentries (one of which records the fixtures moving 3.4.11 → 3.5.2), a doc-comment inSignatureErasure.scalanaming thedaml-lf-archive3.4.11 API, and an opaque fixture string incheck-license-headers.test.sh.On the value
3.5.2 is the newest
damlcthat exists — the highest tag undercomponents/damlc, with the3.5,devnet,testnetandmainnetchannel tags all resolving to it. Note that the newest SDK is 3.5.7, butdamlc_versionnames a component, and passing an SDK version clears the regex inresolve-inputs.sh:53and then fails at component pull.daml-script, driven by the same input (_publish-dar-packages.yaml:140), tops out at 3.5.2 as well.Verification
Planned before the release tag: a
publish-splice.yamldispatch withdry_run=true, which exercises the component pull and the DAR processing without touching nuget.org or the release counters.No CHANGELOG entry: publish-pipeline tooling, no emitted output and no public-surface change.