feat(tikv/client-c): sticky lgtm label when new commit coming

[wuhuizuo]

No description provided.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Based on the Pull Request title and the diff provided, it seems that the change is related to adding the tikv/client-go repository as one of the repositories that should have a "sticky" LGTM label when new commits are made. This means that the LGTM label will not be removed when new commits are pushed to the repository.

However, there is no description provided for the Pull Request. It would be helpful to have more information about why this change is being made and what problem it is solving.

As for potential problems, it is possible that this change could cause confusion for contributors who are used to the LGTM label being removed when they push new commits. They may not realize that the label is now "sticky" and could continue to add new LGTM labels unnecessarily.

A possible suggestion to address this issue would be to add a comment to the Pull Request template explaining the change and reminding contributors that the LGTM label is now "sticky". Additionally, it might be helpful to communicate this change in a GitHub announcement to all contributors to ensure everyone is aware of the change.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Based on the pull request title and description, it seems that this change is related to adding a feature to the tikv/client-c repository. However, the pull request description is empty, so it is difficult to determine the exact changes made or the reason for the change.

Looking at the diff, it appears that the change adds the tikv/client-c repository to the list of repositories that should have a "lgtm" label added when a new commit is made. This change seems reasonable and straightforward.

However, it's worth noting that the pull request description is empty. It's important to have clear and concise descriptions that explain the purpose of the change, any potential issues or limitations, and any necessary context. It would be helpful to have more information about why this change was made and how it affects the system as a whole.

As for fixing suggestions, I would recommend adding a more detailed description to the pull request, explaining the purpose of the change and any potential issues or limitations. Additionally, it may be helpful to run tests to ensure that this change does not affect the functionality of the system. Finally, it may be helpful to have a peer review the code changes to ensure that they are implemented correctly and do not introduce any new issues.

[wuhuizuo]

/approve

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: wuhuizuo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• apps/OWNERS [wuhuizuo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment