-
Notifications
You must be signed in to change notification settings - Fork 16
implement reusable workflows for module integration testing #75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement reusable workflows for module integration testing #75
Conversation
|
The created documentation from the pull request is available at: docu-html |
| required: false | ||
| type: string | ||
| default: 'bl-x86_64-linux' | ||
| ref_int_ref: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get these two: ref_int_ref and 'ref_int_repo`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ref = commit/branch/tag ?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's target_branch_in_integration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is about referencing the ref_int repo. Mainly I need ref for the checkout later. The repo is to enable users to use this workflow also in a private clone.
ref_int_ref = commit/branch/tag
ref_int_repo = eclipse-score/reference_integration (or your private org)
|
LGTM, but it wouldn't hurt to add some documentation about the usage. Maybe add a section in the README? |
- Refactor Python tooling to use shared Module dataclass
* Created tools/models/module.py with centralized module schema
* Added methods: from_dict, parse_modules, owner_repo, to_dict
* Migrated scripts to use dataclass: update_module_latest.py,
update_module_from_known_good.py, override_known_good_repo.py,
known_good_to_workspace_metadata.py, get_module_info.py
* Eliminates duplicate parsing logic across tools
- Clean up override_known_good_repo.py
* Renamed --repo-override to --module-override
* Removed backward compatibility for deprecated flags
* Extracted write_known_good() function for better reusability
* Updated examples to reflect supported formats only
- Improve workflow documentation
* Clarified ref_int_repo and ref_int_ref semantics in smoke-test workflow
* Added detailed usage notes for private fork support
* Updated workflow steps to use --module-override flag
* Enhanced input descriptions for runner label selection
- Remove generated artifact from git
* Deleted known_good.updated.json (build output)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 11 out of 11 changed files in this pull request and generated 5 comments.
Comments suppressed due to low confidence (1)
tools/update_module_latest.py:102
- Inconsistency in branch serialization. In
write_known_good, the branch is always written if present, but inModule.to_dict()(line 108 of module.py), the branch is only written if it differs from 'main'. This inconsistency can lead to the branch field being included unnecessarily in the output, conflicting with the Module class's design. Consider usingm.to_dict()or only writing branch when it's not 'main'.
if m.branch:
mod_dict["branch"] = m.branch
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Output the content as a JSON string | ||
| echo "known_good_updated<<EOF" >> $GITHUB_OUTPUT | ||
| cat known_good.updated.json >> $GITHUB_OUTPUT | ||
| echo "EOF" >> $GITHUB_OUTPUT |
Copilot
AI
Jan 16, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using multiline output for potentially large JSON content could hit GitHub Actions output size limits for large known_good.json files. Consider using artifacts exclusively for passing this data between jobs instead of job outputs, as artifacts are already being uploaded at line 120-123.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can live with both solutions. @AlexanderLanin what is your opinion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Artifacts between actions is most likely best as that could also enable you (depending on how it's set up) to download them and see what is going wrong.
At least I think that is an option then.
| required: false | ||
| type: string | ||
| default: 'bl-x86_64-linux' | ||
| repo_runner_labels: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the runner provided by the caller, or would it be better here in env?
| # "[\"self-hosted\",\"linux\",\"x64\"]"). | ||
| # - target_branch (string, optional, default: main): Ref/branch to checkout. | ||
| # | ||
| # Repository Variables: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any idea from which repo this is used? The caller, this one, or reference_integration?
resolves eclipse-score/score#1852