Closed cicoyle closed 10 months ago
@cicoyle did you take the time to investigate what was being done?
This is already automated exactly the way your describe (actually better because we do not generate noisy PR - we have dynamic code) - I had done so over a year ago. Our CI always uses the latest RC or latest released version of Dapr Runtime and CLI. Additionally, there is even a way to run the workflow against a specific runtime or CLI commit.
Please review the Github workflow code or a recent test run of the validate-examples
workflow to confirm this behavior. I will close this issue in the coming days.
Note that the tox -e examples
command uses whichever version of Dapr you have installed locally. So of course you must install the version you wish to use. Our CI/CD does exactly that.
By design it is not the concern of the tox
command to install Dapr and the Dapr CLI itself.
It would be nice to have an automated process that listens for a new tag to be pushed to the
dapr/dapr
repo &&dapr/cli
that updates the version accordingly so we are always up to date on changes and can automate our release candidate testing. This should be automated to minimize the manual steps in the release process.I propose adding a GitHub Action Workflow to
dapr/python-sdk
that listens for a new tag on thedapr/dapr
repo &&dapr/cli
and auto creates a Pull Request that updates that accordingly. Example updates. Protos might need to be updated/automated with this as wellNote: Use the
DAPR_BOT
secret