timothyb89
commented
6 years ago Example: monasca/monasca-docker#324. Makes changes to and releases a new version of a semver module. With this workflow the version bump in grafana/build.yml and .env would be automatically created by the pr-bot in a follow-up PR. A comment on the user's PR might look like:
Modules affected by this change:
- [ ]
grafana- 2 downstream modules
No modules have been selected for release. Click a checkbox above or comment @monasca-ci release <modulename> [level] to perform a release.
If the user clicks the checkbox it will edit the bot's comment. All allowed users may not be able to edit comments, so they can also comment by @-ing the bot. Clicking a checkbox results in a patch release by default, and @-syntax can be used to specify a major or minor release instead.
If a release is specified the bot will update its comment (and perhaps leave another comment acknowledging the user request). If a user requests a minor update:
Modules affected by this change:
- [x]
grafana- minor - 2 downstream modules
The following modules will be released:
grafana: new minor version4.0.0-1.3.0, updating:docker-composein monasca-dockermonascain monasca-helm
Click a checkbox above or comment @monasca-ci release <modulename> [level] to perform a release. Don't want to release? Uncheck or @monasca-ci release <modulename> to toggle.
Once the change is merged the bot will file release PRs and should leave another comment linking to them.
With release plugins (#9) and repository hooks (#19) we have a decent story for managing the whole CI/CD process, at least on the backend. However, we still need to give users control over how and when a change is is built and released. Ideally this should integrate directly with GitHub issues/pull requests and we should avoid having any external UI.
One idea is for the bot to detect changed modules in a particular PR. It can then leave a comment on the PR users can interact with. Examples in followup comments.