Skip to content

Conversation

@MrCreosote
Copy link
Member

This restores the original Java server ver field format of <module version>-<relase version>. It provides more information for the user and allows the kb_sdk_plus tests to pass.

This restores the original Java server `ver` field format of `<module
version>-<relase version>`. It provides more information for the user
and allows the kb_sdk_plus tests to pass.
@MrCreosote MrCreosote requested a review from bio-boris August 11, 2025 17:59
@bio-boris bio-boris requested a review from Copilot August 11, 2025 18:01
Copy link
Collaborator

@bio-boris bio-boris left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR restores the original Java server format for the provenance action ver field, changing it from just the service version to a combined format of <module version>-<service version>. This change provides more detailed version information and ensures compatibility with kb_sdk_plus tests.

  • Updates the ver field format in MethodRunner.py to include both module and service versions
  • Adds comprehensive test coverage for provenance functionality in the callback server integration tests

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
JobRunner/MethodRunner.py Updates the provenance action ver field to combine module version and service version
test/test_callback_server_integration.py Expands existing test to include provenance setting and validation

"version": "1.1"
}

resp = _post(port, {"method":"CallbackServer.get_provenance"})
Copy link

Copilot AI Aug 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing space after colon in dictionary literal. Should be {"method": "CallbackServer.get_provenance"}

Suggested change
resp = _post(port, {"method":"CallbackServer.get_provenance"})
resp = _post(port, {"method": "CallbackServer.get_provenance"})

Copilot uses AI. Check for mistakes.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

'code_url': 'https://github.com/kbasetest/njs_sdk_test_1',
'commit': '366eb8cead445aa3e842cbc619082a075b0da322',
'name': 'njs_sdk_test_1',
'ver': '0.0.3-dev'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, it can't have a version and a dev at the same time, can it? I thought in order to have a version it must be beta or release?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it always has a version and something to identify the release info - either release/dev/beta or a commit

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what would ver look like if it wasn't released?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whatever the version is in the kbase.yml file

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So 0.0.3-dev and 0.0.3-beta and 0.0.3-prod could all have the same commit or a different commit depending on the registration status in the catalog.. So what is the point of this field? Shouldn't we just be returning the git commit hash?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So 0.0.3-dev and 0.0.3-beta and 0.0.3-prod could all have the same commit or a different commit depending on the registration status in the catalog.

For dev that's true, beta and release would have to have the same git commit I think. IIRC the catalog forces a version bump on any change

So what is the point of this field?

It helps the user understand what code ran and is a quick check along those lines. It's a lot easier to figure out the version of a module from the catalog UI given the semantic version than trying to figure it out from the git commit. It also is monotonic which again helps figuring out how old the module is relative to the most recent release

Shouldn't we just be returning the git commit hash?

The info above is redundant to the git commit, yes, but it's helpful for humans as outlined above

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For dev that's true, beta and release would have to have the same git commit I think. IIRC the catalog forces a version bump on any change

Nope, I'm wrong, you could move a new version to beta but not release

@codecov
Copy link

codecov bot commented Aug 11, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.03%. Comparing base (2b0281e) to head (80ffb3d).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #112   +/-   ##
=======================================
  Coverage   81.03%   81.03%           
=======================================
  Files          13       13           
  Lines        1155     1155           
=======================================
  Hits          936      936           
  Misses        219      219           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@MrCreosote
Copy link
Member Author

Codacy is complaining about asserts in tests

@MrCreosote
Copy link
Member Author

@bio-boris confirmed out of band that this is ok to merge

@MrCreosote MrCreosote merged commit 97f394d into main Aug 11, 2025
11 of 12 checks passed
@bio-boris bio-boris mentioned this pull request Aug 15, 2025
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.

3 participants