feat(config): Add new repos for events

[micnncim]

This PR adds the following repositories:

• spinnaker/kleat
• spinnaker/spinnaker-config
• spinnaker/kustomization-base

[ezimanyi]

@micnncim : What spinnakerbot functionality specifically were you hoping to have in these repos? We've been slowly trying to move away from custom spinnakerbot logic and use more standard tools (ex: mergify to merge changes, etc.).

Based on the spinnakerbot functionality you were looking to enable in these repos, we can see whether it makes sense to add a different integration, or if spinnakerbot is the best solution.

[micnncim]

@ezimanyi Thank you for your reply! I Especially, I'd like to unify the conventions of commit messages and PR titles. Currently, some of the commits in these repositories don't follow the conversion.

What do you think of this? To be fair, I don't have a strong opinion of this change.

[micnncim]

IMO, other tools like GitHub Actions would make sense for this purpose as you said 👍 And if we have a consensus, I'm willing to contribute to that 😄

[ezimanyi]

Interesting point about the commit message conventions. I believe the primary reason we enforce those conventions for the Java microservices is that we parse out the commit type (feat/bug/chore/etc.) to figure out how to increment the semantic version number. As the release process for these other repos is different (and involves manually picking a version number) it's not as important in kleat/kustomization-base/spinnaker-config.

But since users of the project are used to conventional commit messages maybe it makes sense to enforce them for these projects? I don't have a strong opinion about whether we should or not.

But if we do want to enforce the commit messages, I wonder if we can find a good Github action for this. And if it works well in kleat maybe even convert the other repositories to use it? There has not been a lot of maintenance of spinnakerbot recently, and we have run into some issues with rate limiting of the Github API, so we've been generally trying to replace the useful parts with Github actions so we can eventually deprecate it.

I'd certainly welcome a contribution for this if you're interested!

[ezimanyi]

This is one example but I have not explored whether there are other options or done any real comparison: https://github.com/marketplace/actions/conventional-commit-checker

[micnncim]

I believe the primary reason we enforce those conventions for the Java microservices is that we parse out the commit type (feat/bug/chore/etc.) to figure out how to increment the semantic version number.

I didn't know the primary reason, thank you for describing that.

But since users of the project are used to conventional commit messages maybe it makes sense to enforce them for these projects?

Yeah, I think it'd be better to enforce a commit message format whether a release process requires or not.

There has not been a lot of maintenance of spinnakerbot recently, and we have run into some issues with rate limiting of the Github API, so we've been generally trying to replace the useful parts with Github actions so we can eventually deprecate it.

Using GitHub Actions would mean we can avoid rate limiting issues in almost all cases and decoupling components for handing GitHub events. So I agree with your idea that it'd be better to replace some parts with GitHub Actions in many repositories of this organization.

[micnncim]

I've looked into GitHub Actions which can do the same things as spinnakerbot functions including commit message conventions. I believe we could replace most of the spinnakerbot's functions with GitHub Actions.

I've found several actions that would be useful for each case. In the following cases, any actions don't consume the API quota though there's also a limitation for GitHub Actions.

• Lint commits messages
  • spinnakerbot: https://github.com/spinnaker/spinnakerbot/blob/master/gh/conventions.py
  • Most of the actions are too opinionated or not so flexible, which don't allow customizing convention rules or warning comment bodies.
  • e.g.) https://github.com/wagoid/commitlint-github-action#results, https://github.com/agenthunt/conventional-commit-checker-action/blob/master/ccc.js#L33-L43
  • https://github.com/actions-ecosystem/action-lint-commits would be better than the others in terms of simplicity and flexibility because it allows any kind of conventions and doesn't take care of how warning messages look like. AFAIK, only this action could completely reproduce the current spinnakerbot's behavior for commit conventions.
• Stale issues
  • spinnakerbot: https://github.com/spinnaker/spinnakerbot/blob/master/policy/stale_issue_policy.py
  • https://github.com/actions/stale would be the best in GitHub Actions, which provides many flexible options.
  • https://github.com/apps/stale would be good too in GitHub Apps.
• Lint PR title
  • Build-in functions work well and if it doesn't meet the demand, we could use other actions which execute regex like https://github.com/actions-ecosystem/action-regex-match
• Allow some commands from comments
  • spinnakerbot: https://github.com/spinnaker/spinnakerbot/blob/master/event/issue_comment_assign_handler.py, https://github.com/spinnaker/spinnakerbot/blob/master/event/label_issue_comment_event_handler.py
  • Some commands like @spinnakerbot add-label can be replaced with something like /add-label or @github-actions add-label for labels and assignees
  • We could use some simple actions like https://github.com/actions-ecosystem/action-add-labels, https://github.com/actions-ecosystem/action-remove-labels, and https://github.com/actions-ecosystem/action-add-assignees
• Post issue comments
  • We can pass the outputs of actions to others. In many cases, we'd like to post them as issue comments.
  • e.g.) https://github.com/peter-evans/create-or-update-comment, https://github.com/actions-ecosystem/action-create-comment

We can start with a few actions in a few repositories and remove some of them if we find they're not useful or don't work well. The small repositories like kleat or kustomziation-base could be a good starting point.

@ezimanyi What do think of this? I don't have a strong opinion on the above ideas. If you find some of them makes sense, I'll consider a way to contribute to this.

[micnncim]

@ezimanyi ^ How about this? Actually, I’m being stuck since GitHub API limit prevents me from removing a stale label as at spinnaker/spinnaker#5569 (comment).

[ezimanyi]

Sorry for my delay in replying here! Thanks so much for doing all that research into alternative ways of handling workflows that spinnakerbot now handles.

First, it looks like spinnakerbot is currently broken so it's not a rate limit that's the issue in this case. We're looking into a fix there so it should be working again soon. Of course this is another reason it would be great to not have the Spinnaker community need to maintain this custom tool when existing tools can do the job.

I think that the highest benefit change from the ones you've listed above would be to implement the stale bot. That seems to be doing exactly what our github actions are trying to do. And (if I recall correctly) this is the only functionality that requires doing a full scan of the issues in each repo (which is expensive for API quota); the others are all event-based. So if we removed the stale-checking from spinnakerbot we could remove all the non-event logic as well.

So if you're interested in contributing I'd suggest starting with stale issues. Thanks!

[ezimanyi]

I just saw an email (on spinnaker/spinnaker#6104) that came from Github actions marking an issue stale. It looks like we actually have been using the stale bot since #5661...but I suspect that because spinnakerbot was also running spinnakerbot has always commented on issues before stalebot found them stale. The recent outage of spinnakerbot is probably why we are starting to see stalebot notifications.

So maybe the work for the "stale issues" is just to deactivate that part of spinnakerbot (and then copy the config to any other repos that have issues).

[micnncim]

Thank your your reply.

maybe the work for the "stale issues" is just to deactivate that part of spinnakerbot

Yeah, seems it should be fine according to your comments 👍