Added ability to pin the neoboard-sdk commit by segnord · Pull Request #121 · nordeck/matrix-neoboard-standalone

segnord · 2026-07-31T14:49:07Z

✔️ Checklist

A changeset describing the change and affected packages (more info).
Added or updated documentation.
Tests for new functionality and regression tests for bug fixes.
Screenshots or videos attached (for UI changes).
All your commits have a Signed-off-by line in the message (more info).

We will use a "sdk.version" file to know which neoboard-sdk commit to pull in order to build the standalone version, instead of relying in the HEAD commit of the sdk.

changeset-bot · 2026-07-31T14:49:11Z

⚠️ No Changeset found

Latest commit: ad05a72

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

HarHarLinks · 2026-08-05T13:43:53Z

which alternatives have you considered and why are they not viable?

it seems unintuitive to me to use a "pull" model rather than "push" model. why isn't the CI job to update the react sdk version used on main not part of the matrix-neoboard repo instead?

segnord · 2026-08-05T19:00:35Z

which alternatives have you considered and why are they not viable?

The alternative are

Upgrade our yarn version from Classic to a more modern one (yarn berry) that can store the commit in the lockfile and can extract the SDK library from the neoboard monorepo in package.json (using a specially prepared link). This has a potential to break the existing dev experience (I got warnings that it may not support node_mudules or vite and has to be configured specifically).
A manual process: before the release we change the ci.yaml to a fixed commit manually in a separate PR, merge the Version Package Commit that will create a release tag. Then immediately revert the ci.yaml to use HEAD as before in a new PR.

it seems unintuitive to me to use a "pull" model rather than "push" model. why isn't the CI job to update the react sdk version used on main not part of the matrix-neoboard repo instead?

You mean the builds and commits from neoboard should somehow influence which sdk version has to be used in the standalone project instead of it trying to use HEAD until we get to a release PR (in that case the pinned version is used from the latest feature merge to main)?

segnord · 2026-08-07T10:19:37Z

Note: with the provided CI workflow if we want to release with a specific SDK commit in mind (not the calculated HEAD of the sdk repo used in the latest feature PR merge) we can always push a commit into the "Verson Package" PR with the sdk.version.

…file and updated to the latest commit by the github actions Signed-off-by: segnord <sergey.vasiluk@nordeck.net>

…version pinning scenarios, also a guard condition added to pin the neoboard sdk version to the file in case the sdk has been updated since the last standalone feature merge.

Signed-off-by: Milton Moura <miltonmoura@gmail.com>

maheichyk

It looks fine to use a neoboard react sdk commit hash in the file and use it.

However I think how it is done currently is a way more complicated then it should/could be. There are also issues that could happen and there are comments to that.

In my opinion we could simply use sdk.version as is always and update it in any PR when needed and don't rely on this implicit latest commit fetching from sdk at all.

Edit: typo fixed

maheichyk · 2026-09-09T13:25:35Z

+        run: |
+          RESOLVED_SHA=$(tr -d '[:space:]' < sdk.version)
+
+          if [[ -n "$NEOBOARD_REF" ]]; then


Do we need NEOBOARD_REF at all? It was added to this PR. Why not just to update sdk.version in a PR itself?

This parameter existed before this PR, it was empty so it just checkout HEAD always, but you could enter your value.

maheichyk · 2026-09-09T13:28:21Z

+            # A release PR merge has no pending changesets and must build from
+            # the pin committed in that release commit. Feature merges track
+            # the latest SDK and persist the resolved SHA in the release PR.
+            PENDING_CHANGESETS=$(find .changeset -maxdepth 1 -name '*.md' ! -name 'README.md' | wc -l)


We can also merge a PR without changeset to main with no changesets, it will not be a release PR.

This usecase is covered in the "Renovate bot" section. Merges without a changeset won't create a new release.

maheichyk · 2026-09-09T13:37:52Z

+            # the latest SDK and persist the resolved SHA in the release PR.
+            PENDING_CHANGESETS=$(find .changeset -maxdepth 1 -name '*.md' ! -name 'README.md' | wc -l)
+            if [[ "$PENDING_CHANGESETS" -gt 0 ]]; then
+              RESOLVED_SHA=$(git ls-remote https://github.com/nordeck/matrix-neoboard.git refs/heads/main | cut -f1)


This is really strange I would say that we basically ignore the sdk.version and just take a latest from sdk. What is the whole purpose of sdk.version then?

A merge commit will use latest from sdk, not from sdk.version.

Just think about it: use a sdk.version to develop a feature in pull request with a particular sdk.version and use another version when merged to main. Or rerun a failed job for some reason of merge commit and use another latest sdk commit with a new run.

I think one of the main purposes of this PR is to make deterministic builds.

Release only happens when there are 0 changeset files and the project.json version is bumped. This is managed by that special PR the changeset bot maintains, sdk.version file is used then. Other times it's just being updated in the release PR automatically to follow the HEAD.

maheichyk · 2026-09-09T14:07:57Z

+            PENDING_CHANGESETS=$(find .changeset -maxdepth 1 -name '*.md' ! -name 'README.md' | wc -l)
+            if [[ "$PENDING_CHANGESETS" -gt 0 ]]; then
+              RESOLVED_SHA=$(git ls-remote https://github.com/nordeck/matrix-neoboard.git refs/heads/main | cut -f1)
+              echo "Pending changesets found: using matrix-neoboard main at $RESOLVED_SHA."


It also also updates "Version Packages" with latest sdk version, not with sdk.version, so a release will happen with something you may not try before. It feels like you would use a dependency in your PR and now suddently it gets bumped in release.

Or CI could suddenly just fail in "Version Packages".

Additionally "Version Packages" are forced pushed by changesets, so if something is changed in "Version Packages" manually like sdk.version it gets overridden with next PR with changeset merged.

Yes, that's the idea, the sdk.version is getting updates on every merge to main. But when you merge the "Version Packages" to main, it's when it won't use HEAD, but the version from the file and a release will trigger.

maheichyk · 2026-09-09T14:11:58Z

+        # This action creates/updates the "Version Packages" pull request.
+        # It has 2 outcomes depending if the workspace contains any changeset files and package.json version.
+        #   changeset files exist (version): Creates/updates the "Version packages" pull request.
+        #                          Bumps the package.json version.
+        #                          Writes the SDK used by this build to sdk.version.
+        #   no changeset files (publish): tags the current commit with the new semver.


When I read it if feels confusing, things are mixed up together: "Version Packages", "2 outcomes", "any", "and".

It makes to to feel like you have to check what it does and there are just few command, maybe could improve.

It's just the changesets github action has version and publish outcomes depending on the kind of PR is merged, that may not be obvious at a glance.

maheichyk · 2026-09-09T14:16:50Z

@@ -0,0 +1 @@
+67758ec8c804e5a2aa3be5b6e0810e45b51dabc8


I feels fine to store it in file. But I think file should be better named, sdk is very general. Something with neoboard maybe up to matrix-neoboard-react-sdk.

There's a sdk_version.sh file so the naming followed it.

maheichyk · 2026-09-09T14:18:57Z

    "depcheck": "depcheck --ignores=@vitest/coverage-v8,@changesets/cli,@swc/core,@testing-library/dom,@testing-library/jest-dom,@testing-library/react,@testing-library/react-hooks,@typescript-eslint/eslint-plugin,@typescript-eslint/parser,prettier-plugin-organize-imports,identity-obj-proxy",
    "deduplicate": "yarn-deduplicate",
    "translate": "i18next-cli extract --sync-primary",
+    "changeset:version": "yarn changeset version && node scripts/update-sdk-version.mjs",


Do we need changeset:version in package.json, people should not use it, ci.yaml should be possible to be updated to use command directly. Maybe we don't need this at all.

Initially the PR didn't have it and it just wrote the SHA to file. The new script contains a SHA structure verification. @mgcm may explain better.

maheichyk · 2026-09-09T14:22:24Z

+        env:
+          NEOBOARD_REF: ${{ github.event.inputs.neoboard_ref }}
+        run: |
+          RESOLVED_SHA=$(tr -d '[:space:]' < sdk.version)


Let's consider to use sdk.version always and don't try to magically replace/refresh it's value to latest in sdk. I think this could remove all the confusion and get things easy to understand. Anyone can just update sdk.version in any PR.

The idea was to pin the commit only during release and never think about manually tracking the HEAD of the SDK repo during feature commits to main (same workflow as befofore this PR).

maheichyk · 2026-09-09T14:23:43Z

+The pinned commit lives in [`sdk.version`](../sdk.version) at the repo root.
+Whether it gets refreshed before a build - and what ends up tagged - depends on the trigger.


I think the whole document actually shows how confusingly sdk.version is currently been used.

The release process isn't trivial, the scripts try keep up with sdk main branch automatically while freezing the version predictably for a release with frozen commit hashes.

segnord

Commented

segnord · 2026-09-09T16:40:06Z

+        env:
+          NEOBOARD_REF: ${{ github.event.inputs.neoboard_ref }}
+        run: |
+          RESOLVED_SHA=$(tr -d '[:space:]' < sdk.version)


The idea was to pin the commit only during release and never think about manually tracking the HEAD of the SDK repo during feature commits to main (same workflow as befofore this PR).

segnord · 2026-09-09T16:48:23Z

+        run: |
+          RESOLVED_SHA=$(tr -d '[:space:]' < sdk.version)
+
+          if [[ -n "$NEOBOARD_REF" ]]; then


This parameter existed before this PR, it was empty so it just checkout HEAD always, but you could enter your value.

segnord · 2026-09-09T16:50:31Z

+            # A release PR merge has no pending changesets and must build from
+            # the pin committed in that release commit. Feature merges track
+            # the latest SDK and persist the resolved SHA in the release PR.
+            PENDING_CHANGESETS=$(find .changeset -maxdepth 1 -name '*.md' ! -name 'README.md' | wc -l)


This usecase is covered in the "Renovate bot" section. Merges without a changeset won't create a new release.

segnord · 2026-09-09T16:54:53Z

+            # the latest SDK and persist the resolved SHA in the release PR.
+            PENDING_CHANGESETS=$(find .changeset -maxdepth 1 -name '*.md' ! -name 'README.md' | wc -l)
+            if [[ "$PENDING_CHANGESETS" -gt 0 ]]; then
+              RESOLVED_SHA=$(git ls-remote https://github.com/nordeck/matrix-neoboard.git refs/heads/main | cut -f1)


Release only happens when there are 0 changeset files and the project.json version is bumped. This is managed by that special PR the changeset bot maintains, sdk.version file is used then. Other times it's just being updated in the release PR automatically to follow the HEAD.

segnord · 2026-09-09T16:57:00Z

+            PENDING_CHANGESETS=$(find .changeset -maxdepth 1 -name '*.md' ! -name 'README.md' | wc -l)
+            if [[ "$PENDING_CHANGESETS" -gt 0 ]]; then
+              RESOLVED_SHA=$(git ls-remote https://github.com/nordeck/matrix-neoboard.git refs/heads/main | cut -f1)
+              echo "Pending changesets found: using matrix-neoboard main at $RESOLVED_SHA."


Yes, that's the idea, the sdk.version is getting updates on every merge to main. But when you merge the "Version Packages" to main, it's when it won't use HEAD, but the version from the file and a release will trigger.

segnord · 2026-09-09T16:59:47Z

+        # This action creates/updates the "Version Packages" pull request.
+        # It has 2 outcomes depending if the workspace contains any changeset files and package.json version.
+        #   changeset files exist (version): Creates/updates the "Version packages" pull request.
+        #                          Bumps the package.json version.
+        #                          Writes the SDK used by this build to sdk.version.
+        #   no changeset files (publish): tags the current commit with the new semver.


It's just the changesets github action has version and publish outcomes depending on the kind of PR is merged, that may not be obvious at a glance.

segnord · 2026-09-09T17:08:12Z

+The pinned commit lives in [`sdk.version`](../sdk.version) at the repo root.
+Whether it gets refreshed before a build - and what ends up tagged - depends on the trigger.


The release process isn't trivial, the scripts try keep up with sdk main branch automatically while freezing the version predictably for a release with frozen commit hashes.

segnord · 2026-09-09T17:12:25Z

    "depcheck": "depcheck --ignores=@vitest/coverage-v8,@changesets/cli,@swc/core,@testing-library/dom,@testing-library/jest-dom,@testing-library/react,@testing-library/react-hooks,@typescript-eslint/eslint-plugin,@typescript-eslint/parser,prettier-plugin-organize-imports,identity-obj-proxy",
    "deduplicate": "yarn-deduplicate",
    "translate": "i18next-cli extract --sync-primary",
+    "changeset:version": "yarn changeset version && node scripts/update-sdk-version.mjs",


Initially the PR didn't have it and it just wrote the SHA to file. The new script contains a SHA structure verification. @mgcm may explain better.

segnord · 2026-09-09T17:13:37Z

@@ -0,0 +1 @@
+67758ec8c804e5a2aa3be5b6e0810e45b51dabc8


There's a sdk_version.sh file so the naming followed it.

# Conflicts: # .github/workflows/publish-release.yml

segnord · 2026-09-09T17:18:59Z

Conflicts resolved by merging main

segnord requested a review from a team as a code owner July 31, 2026 14:49

segnord changed the title ~~The neoboard-sdk is now pinned~~ The neoboard-sdk commit has is pinned Jul 31, 2026

segnord changed the title ~~The neoboard-sdk commit has is pinned~~ The neoboard-sdk commit is pinned Jul 31, 2026

segnord changed the title ~~The neoboard-sdk commit is pinned~~ Added ability to pin the neoboard-sdk commit Jul 31, 2026

segnord and others added 4 commits August 27, 2026 17:40

feat: The neoboard-sdk is now pinned using a dedicated "sdk.version" …

1b2ccb2

…file and updated to the latest commit by the github actions Signed-off-by: segnord <sergey.vasiluk@nordeck.net>

feat: added docs/sdk_version_pin.md that describes the automated sdk …

309667d

…version pinning scenarios, also a guard condition added to pin the neoboard sdk version to the file in case the sdk has been updated since the last standalone feature merge.

Persist sdk pin for releases

19e8d9c

Signed-off-by: Milton Moura <miltonmoura@gmail.com>

Add composite tags with both standalone + sdk version

5e4fe44

Signed-off-by: Milton Moura <miltonmoura@gmail.com>

mgcm force-pushed the nic/feat/NEO-1765_pin_sdk branch from 5986999 to 5e4fe44 Compare August 27, 2026 17:40

segnord commented Aug 28, 2026

View reviewed changes

Comment thread .github/workflows/ci.yml

maheichyk requested changes Sep 9, 2026

View reviewed changes

maheichyk reviewed Sep 9, 2026

View reviewed changes

Comment thread .github/workflows/publish-release.yml

segnord commented Sep 9, 2026

View reviewed changes

Merge branch 'main' into nic/feat/NEO-1765_pin_sdk

ad05a72

# Conflicts: # .github/workflows/publish-release.yml

		The pinned commit lives in [`sdk.version`](../sdk.version) at the repo root.
		Whether it gets refreshed before a build - and what ends up tagged - depends on the trigger.

		@@ -0,0 +1 @@
		67758ec8c804e5a2aa3be5b6e0810e45b51dabc8

		@@ -0,0 +1 @@
		67758ec8c804e5a2aa3be5b6e0810e45b51dabc8

Uh oh!

Conversation

segnord commented Jul 31, 2026

Uh oh!

changeset-bot Bot commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ No Changeset found

Uh oh!

HarHarLinks commented Aug 5, 2026

Uh oh!

segnord commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

segnord commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

maheichyk left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

segnord left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

changeset-bot Bot commented Jul 31, 2026 •

edited

Loading

segnord commented Aug 5, 2026 •

edited

Loading

segnord commented Aug 7, 2026 •

edited

Loading

maheichyk left a comment •

edited

Loading

segnord commented Sep 9, 2026 •

edited

Loading