Hi Edward,
Thank you so much for raising this.
In my experience, a single PR which contains the change of both the repos and sigs definitons would be a good practice. While as we may know, the repo in sigs is not in the form of structural definition, so it's impossible to add an extra rename attribute for a single repo. So in the current situation, I would recommend to separate into two PRs. In prior to changing the sigs definition, the PR for repos definitions must be merged first. Although the CI would fail with complaining the new repo does not exit, it could be also considered as a reminder for telling us to finish the renaming operations by changing the sigs definition accordingly.
I've admitted that it's not a ideal solution. Please let me know what you think. Thank you.
Regards, Joey
On Thu, Mar 19, 2020 at 3:49 PM Edward Lee freesky.edward@gmail.com wrote:
hi, Joey
Thanks for the efforts. both of them are very helpful.
Regarding to `rename repo` feature, I would suggest two cases we'd better think it over.
- As you may know, currently there are two major cases:
- one is to add repo in repository[1] and sig definition with
defferent PRs, sig definition must follow repo is ready. - the other case is to update repository and sigs definition within one PR. both of the two cases will be ok. but to `rename` case, if a PR was created to update one repo's name, does it require to update the sigs definitions[2] with the same PR or seperated PR?
- currently, we have the CI tasks to check whether the sig definition is
right or not. that includes repository name check and user id existing check via send request to gitee API. I stongly recommend to consider whether will it work well for rename PR since the repository not really changed, however sigs definition changed.
anyhow, looking forward to the features. thanks very much.
[1]https://gitee.com/openeuler/community/tree/master/repository [2]https://gitee.com/openeuler/community/blob/master/sig/sigs.yaml
On Tue, Mar 17, 2020 at 5:49 PM joey via Infra infra@openeuler.org wrote:
Hi all:
I’m Joey and from infrastructure team of openEuler. So glad to see you guys and hope everybody is doing well.
I’m writing here to have a brief introduction to the new features provided by ci-bot. We believe they would be helpful for your repository management.
As it’s known to us, ci-bot is an automation system to handle lots of infrastructure stuff, such as gitee web hook events, repository management, owner management and etc. For more details about our lovely ci-bot, please refer to https://gitee.com/openeuler/ci-bot. For now, please let me elaborate how you can make use of the two features to ease the repository management.
- Add commentable property for repository definition in openeuler.yaml
or src-openeuler.yaml under openeuler/community. PR is: https://gitee.com/openeuler/ci-bot/pulls/26 .
Previously users could leave a comment at the index page of the
project, which is a great feature provided by Gitee. While as we all know, the more conventional way is posting an issue request for questions/bugs/features. So after discussion, we finally consider to disable the comment-to-repository feature for all repositories. So here comes to this functionality, which adds an extra commentable property. If it’s not specified, the default value is false of boolean type.
Actually, you DO NOT need to pay any attention to this new property
since non-commentable repository is strongly recommended. Just think it never exists. The example is shown as below,
community: openeulerrepositories: - name: A-Tune description: "" type: public commentable: false # User CAN NOT see or leave comment to repository - name: ci-bot description: "" type: public commentable: true # Users CAN see and leave comment to repository - name: community description: "" type: public # User CAN NOT see or leave comment to repository
- Add rename_from property for repository definition in openeuler.yaml
or src-openeuler.yaml under openeuler/community. PR is: https://gitee.com/openeuler/ci-bot/pulls/27 .
Please let me take a real case for example. In PR
https://gitee.com/openeuler/community/pulls/128, iSulad team wants to change the names of three repositories:
- iSulad-kit ===> iSulad-img
- iSulad-lxcfs-toolkit ===> lxcfs-tools
- iSulad-tools ===> syscontainer-tools
As the PR is shown to us, the code diff is as below, which leaded
ci-bot to completely remove the old repository and create a new empty one with the new name, causing loss of all the existing issues and PRs.
- - name: iSulad-kit+ - name: iSulad-img description: ""- - name: iSulad-lxcfs-toolkit+ - name: lxcfs-toolkit description: ""- - name: iSulad-tools+ - name: syscontainer-tools description: ""While after the PR has been merged, the diff would be like the
following. This could make use of the newly supported renaming-repository Gitee OpenAPI to keep all the issues and PRs unchanged.
- - name: iSulad-kit+ - name: iSulad-img description: ""+ rename_from: iSulad-kit- - name: iSulad-lxcfs-toolkit+ - name: lxcfs-toolkit description: ""+ rename_from: iSulad-lxcfs-toolkit- - name: iSulad-tools+ - name: syscontainer-tools description: ""+ rename_from: iSulad-toolsWhile it should noted that rename_from is not declarative but
imperative cause it will take effect only for once and not stored in DB. So if we remove it from repository definition after renaming operation has been finished, nothing will happen.
Hopefully I have explained clear enough. Currently the new functionalities are not in production yet and your feedback is rather important to us. So please reply this email for further discussion as soon as you have any doubt. Looking forward to your feedback.
Take care!
Best regards, Joey
Infra mailing list -- infra@openeuler.org To unsubscribe send an email to infra-leave@openeuler.org
--
Edward Lee
Email: freesky-edward@gamil.com Phone: 0086-18200191386 Twitter: https://twitter.com/EdwardL0086 Address: Chengdu City, Sichuan Privince, China _______________________________________________ Infra mailing list -- infra@openeuler.org To unsubscribe send an email to infra-leave@openeuler.org