Hello Team,
I was about to test your SDK Publish workflow from my fork and wanted to provide a clear warning about potential risks. This workflow can automatically publish your SDKs (JavaScript and Python) and push commits to the main repository. Here are the key points you should be aware of:
What the workflow does:
Allows selecting which SDK to publish: js, python, or both.
Requires a version bump type: patch (1.0.0 → 1.0.1), minor (1.0.0 → 1.1.0), or major (1.0.0 → 2.0.0).
Supports a dry_run mode to simulate the process without actual publishing.
When run for real, it:
Clones the repo.
Updates version numbers in relevant files.
Builds and tests the package.
Publishes to npm (JS) or PyPI (Python).
Commits and pushes the version bump back to GitHub.
Risks for forks and main repository:
Accidental publishing: Selecting the wrong bump type will push an unintended version to npm or PyPI.
Repository impact: The workflow creates a commit for the version bump and pushes it automatically on main branch, without testing in dev branch, which is not is existing. If run from a fork with write access or misconfigured remotes, it can affect the main repo.
Local clone changes: The workflow modifies version files. Any uncommitted changes could be overwritten.
Example of a risk scenario (DO NOT EXECUTE):
Fictitious example input for manual dispatch
sdk: both
bump: major
dry_run: false
If run unintentionally, this would:
Publish both SDKs as a major version update.
Push commits to the repository.
Recommendations for forkers:
Always run a dry_run first, on another branch, which is not implemented for forkers.
Ensure your fork or clone is clean and up to date, with an enforced upstream.
Never trigger the workflow manually if you are unsure of the consequences.
Communicate with maintainers before attempting a real publish.
This message is purely to explain the risks and avoids providing executable payloads that a malicious actor could use.
Thank you for your attention,
Regards
Hello Team,
I was about to test your SDK Publish workflow from my fork and wanted to provide a clear warning about potential risks. This workflow can automatically publish your SDKs (JavaScript and Python) and push commits to the main repository. Here are the key points you should be aware of:
What the workflow does:
Allows selecting which SDK to publish: js, python, or both.
Requires a version bump type: patch (1.0.0 → 1.0.1), minor (1.0.0 → 1.1.0), or major (1.0.0 → 2.0.0).
Supports a dry_run mode to simulate the process without actual publishing.
When run for real, it:
Clones the repo.
Updates version numbers in relevant files.
Builds and tests the package.
Publishes to npm (JS) or PyPI (Python).
Commits and pushes the version bump back to GitHub.
Risks for forks and main repository:
Accidental publishing: Selecting the wrong bump type will push an unintended version to npm or PyPI.
Repository impact: The workflow creates a commit for the version bump and pushes it automatically on main branch, without testing in dev branch, which is not is existing. If run from a fork with write access or misconfigured remotes, it can affect the main repo.
Local clone changes: The workflow modifies version files. Any uncommitted changes could be overwritten.
Example of a risk scenario (DO NOT EXECUTE):
Fictitious example input for manual dispatch
sdk: both
bump: major
dry_run: false
If run unintentionally, this would:
Publish both SDKs as a major version update.
Push commits to the repository.
Recommendations for forkers:
Always run a dry_run first, on another branch, which is not implemented for forkers.
Ensure your fork or clone is clean and up to date, with an enforced upstream.
Never trigger the workflow manually if you are unsure of the consequences.
Communicate with maintainers before attempting a real publish.
This message is purely to explain the risks and avoids providing executable payloads that a malicious actor could use.
Thank you for your attention,
Regards