Re: GitLab and BuildBot
On 10/2/2023 7:36 pm, jan.som...@dlr.de wrote: >> -Original Message- >> From: devel On Behalf Of Chris Johns >> Sent: Donnerstag, 9. Februar 2023 23:26 >> To: Christian MAUDERER ; >> RTEMS Devel >> Subject: Re: GitLab and BuildBot >> >> >> Thanks and it is great to get the feedback. We normally only ever hear from >> people when it does not work :) >> > > Hi Chris, > > I wasn't aware of this as I am not so much involved with the trac. > What I got from this thread is that there is currently work on the way to > move the git repositories and development process to a (self-hosted) Gitlab. The server gear is 9 years old and Amar is updating, upgrading and sorting out a range of long standing issues in that equipment that have slowly appeared. It is an amazing effort and technically challenging given the minimum downtime we have experienced so far. Once done we can move to patch management and CI. We have reviewed what is available and what we can self host and gitlib is the best fit and all those with commit access seem comfortable with this choice. Discussions with Amar indicate he will bring up an instance unfunded and my understanding is funding is needed for a fully featured system. If the tickets do not indicate this please reach out to Amar on a...@rtems.org. The tickets and project groupings can be found here: https://devel.rtems.org/wiki/FundingProjects > That would be amazing. We use Gitlab internally as well and are quite happy > with it. > > So, looking forward to the new Gitlab. I am also looking forward to it. It is long overdue but for good or bad reasons history seems to indicate this is the RTEMS way! I would also like to mention none of this would be possible without the support of OSU OSL and Lance and his team: https://osuosl.org/ They host all our equipment for free. They have a donate page here: https://osuosl.org/donate/ We all depend on the awesome job they do. Lance keeps an active eye on our equipment and reports to us our security status. Some of this work is based on his reports. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: GitLab and BuildBot
> -Original Message- > From: devel On Behalf Of Chris Johns > Sent: Donnerstag, 9. Februar 2023 23:26 > To: Christian MAUDERER ; > RTEMS Devel > Subject: Re: GitLab and BuildBot > > > Thanks and it is great to get the feedback. We normally only ever hear from > people when it does not work :) > Hi Chris, I wasn't aware of this as I am not so much involved with the trac. What I got from this thread is that there is currently work on the way to move the git repositories and development process to a (self-hosted) Gitlab. That would be amazing. We use Gitlab internally as well and are quite happy with it. So, looking forward to the new Gitlab. Best regards, Jan > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GitLab and BuildBot
Hello Chris, On 2023-02-09 23:26, Chris Johns wrote: On 9/2/2023 6:24 pm, Christian MAUDERER wrote: Hello Chris, On 2023-02-08 23:35, Chris Johns wrote: On 8/2/2023 8:04 pm, Christian MAUDERER wrote: On 2023-02-07 23:37, Chris Johns wrote: On 7/2/2023 9:31 pm, Christian MAUDERER wrote: On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: That shouldn't be a pure decision by the one who pays for the work but one that is (in the optimal case) discussed and specified in the tickets. I did not know that was happening. I am sorry if you think it is and if I gave you that impression. There have been relatively new tickets that changed the status from "needs-funding" to "funded" nearly without delay. That was a bit surprising for me. It seems that the tickets are still updated based on feedback so that is fine and it's great that someone funded them. It just would have been nice if there would have been some announcement for two or three days like "Someone wants to fund the tickets 1, 2 and that part of 4 exactly like they are written now. If there are big objections with the direction, please speak up now." I have never seen EB, your employer, make such an announcement about private commercial in confidence contracts in this way and I would never expect EB to do that so I think it is outrageous you think you can ask this here like this. The funding is a private commercial agreement Amar has and it is no different to the ones your employer makes. Any questions need to be directed to Amar directly but I suggest the questions should be along of the lines of what you can fund. Seems that I exaggerated too much. It's a tendency that I have sometimes as an attempt to be descriptive. I'm sorry if that I haven't been more careful in my choice of words. Thanks and I understand it is not a natural language for you. Of course, it's not relevant for the list whether it's paid or not and who is paying. It doesn't have to have any special form either. But announcements for changes to the devel list are not unusual in general. For bigger changes it's often done before the change. Sometimes vague but it's at least announced (Example: New build system [1], [2], ...). If someone wants to know more or objects the planned changes he can speak up in these mail threads and concerns can be discussed and in the worst case a change can be rejected entirely. For smaller changes everyone just sends patches to the list that are usually accepted and sometimes rejected if someone objects. For infrastructure changes, a patch review after it is done isn't possible. So these are more the big kind of changes that should be announced with at least a few days time for someone to object or discuss. Tickets are nice but they are not very visible. Clearly explaining what is happening is important and if that has not been done then I apologise. The planned work on rtems.org has been split along the lines of infrastructure and services. Infrastructure is stuff no one normally cares about except Amar and myself with oversight by Joel and Gedare. The list includes redundant Cisco firewall updates, base OS updates, movement of jails support, the mess of IPMI+Java+Windows, logs, certs and what ever else the tickets have. The infrastructure lets us provide the services we run. The services we have will run as they have for the last 9 years. The upgraded infrastructure will let add new services such as CI and that is part of the selection process you have kindly participated in. Thanks for the explanation. This list is open and public for the project and its community and I will not tolerant any commercial activity of any type. Sorry, shouldn't have mentioned "Someone wants to fund ...". The tickets already had something similar in the comments, so I didn't think that someone would object as long as it is an anonymous "Someone wants to fund ..." and not "Company X wants to fund ...". Understood. My comment was a reminder to everyone and not specifically you. This discussion is archived so making sure what we are talking about is clear is important. Regarding the tickets, there are many cases over the years of those providing services performing services internally, raising tickets and committing changes. I see no issue here and I am fine with that continuing to happen. Finally, my understanding of the funded tickets is most of the work is to rebuild the servers to be current and capable of running modern CI systems, what ever that ends up being. Maintenance tasks that keep the systems running are fine without an announcement. These are a lot of great work that happens behind the scenes. The maintenance has been happening for nearly 9 years unfunded. A lot of organisations and individuals have created a lot of systems running RTEMS and serviced a lot of clients in that time accessing this system. Lets not lose sight of that :) But these tasks don't change how a user can
Re: GitLab and BuildBot
On 9/2/2023 6:24 pm, Christian MAUDERER wrote: > Hello Chris, > > On 2023-02-08 23:35, Chris Johns wrote: >> On 8/2/2023 8:04 pm, Christian MAUDERER wrote: >>> On 2023-02-07 23:37, Chris Johns wrote: On 7/2/2023 9:31 pm, Christian MAUDERER wrote: > On 2023-02-07 07:03, Chris Johns wrote: >> On 30/1/2023 10:12 pm, Christian MAUDERER wrote: > That shouldn't be a pure decision by the one who pays for the work but one > that > is (in the optimal case) discussed and specified in the tickets. I did not know that was happening. I am sorry if you think it is and if I gave you that impression. >>> >>> There have been relatively new tickets that changed the status from >>> "needs-funding" to "funded" nearly without delay. That was a bit surprising >>> for me. >>> >>> It seems that the tickets are still updated based on feedback so that is >>> fine >>> and it's great that someone funded them. It just would have been nice if >>> there >>> would have been some announcement for two or three days like "Someone wants >>> to >>> fund the tickets 1, 2 and that part of 4 exactly like they are written now. >>> If >>> there are big objections with the direction, please speak up now." >> >> I have never seen EB, your employer, make such an announcement about private >> commercial in confidence contracts in this way and I would never expect EB >> to do >> that so I think it is outrageous you think you can ask this here like this. >> The >> funding is a private commercial agreement Amar has and it is no different to >> the >> ones your employer makes. Any questions need to be directed to Amar directly >> but >> I suggest the questions should be along of the lines of what you can fund. > > Seems that I exaggerated too much. It's a tendency that I have sometimes as an > attempt to be descriptive. I'm sorry if that I haven't been more careful in my > choice of words. Thanks and I understand it is not a natural language for you. > Of course, it's not relevant for the list whether it's paid or not and who is > paying. It doesn't have to have any special form either. > > But announcements for changes to the devel list are not unusual in general. > For > bigger changes it's often done before the change. Sometimes vague but it's at > least announced (Example: New build system [1], [2], ...). If someone wants to > know more or objects the planned changes he can speak up in these mail threads > and concerns can be discussed and in the worst case a change can be rejected > entirely. > > For smaller changes everyone just sends patches to the list that are usually > accepted and sometimes rejected if someone objects. > > For infrastructure changes, a patch review after it is done isn't possible. So > these are more the big kind of changes that should be announced with at least > a > few days time for someone to object or discuss. Tickets are nice but they are > not very visible. Clearly explaining what is happening is important and if that has not been done then I apologise. The planned work on rtems.org has been split along the lines of infrastructure and services. Infrastructure is stuff no one normally cares about except Amar and myself with oversight by Joel and Gedare. The list includes redundant Cisco firewall updates, base OS updates, movement of jails support, the mess of IPMI+Java+Windows, logs, certs and what ever else the tickets have. The infrastructure lets us provide the services we run. The services we have will run as they have for the last 9 years. The upgraded infrastructure will let add new services such as CI and that is part of the selection process you have kindly participated in. >> This list is open and public for the project and its community and I will not >> tolerant any commercial activity of any type. >> > > Sorry, shouldn't have mentioned "Someone wants to fund ...". The tickets > already > had something similar in the comments, so I didn't think that someone would > object as long as it is an anonymous "Someone wants to fund ..." and not > "Company X wants to fund ...". Understood. My comment was a reminder to everyone and not specifically you. This discussion is archived so making sure what we are talking about is clear is important. >> Regarding the tickets, there are many cases over the years of those providing >> services performing services internally, raising tickets and committing >> changes. >> I see no issue here and I am fine with that continuing to happen. >> >> Finally, my understanding of the funded tickets is most of the work is to >> rebuild the servers to be current and capable of running modern CI systems, >> what >> ever that ends up being. >> > > Maintenance tasks that keep the systems running are fine without an > announcement. These are a lot of great work that happens behind the scenes. The maintenance has been happening for nearly 9 years unfunded. A lot of organisations and individuals have created a lot of
Re: GitLab and BuildBot
Hello Chris, On 2023-02-08 23:35, Chris Johns wrote: On 8/2/2023 8:04 pm, Christian MAUDERER wrote: On 2023-02-07 23:37, Chris Johns wrote: On 7/2/2023 9:31 pm, Christian MAUDERER wrote: On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: That shouldn't be a pure decision by the one who pays for the work but one that is (in the optimal case) discussed and specified in the tickets. I did not know that was happening. I am sorry if you think it is and if I gave you that impression. There have been relatively new tickets that changed the status from "needs-funding" to "funded" nearly without delay. That was a bit surprising for me. It seems that the tickets are still updated based on feedback so that is fine and it's great that someone funded them. It just would have been nice if there would have been some announcement for two or three days like "Someone wants to fund the tickets 1, 2 and that part of 4 exactly like they are written now. If there are big objections with the direction, please speak up now." I have never seen EB, your employer, make such an announcement about private commercial in confidence contracts in this way and I would never expect EB to do that so I think it is outrageous you think you can ask this here like this. The funding is a private commercial agreement Amar has and it is no different to the ones your employer makes. Any questions need to be directed to Amar directly but I suggest the questions should be along of the lines of what you can fund. Seems that I exaggerated too much. It's a tendency that I have sometimes as an attempt to be descriptive. I'm sorry if that I haven't been more careful in my choice of words. Of course, it's not relevant for the list whether it's paid or not and who is paying. It doesn't have to have any special form either. But announcements for changes to the devel list are not unusual in general. For bigger changes it's often done before the change. Sometimes vague but it's at least announced (Example: New build system [1], [2], ...). If someone wants to know more or objects the planned changes he can speak up in these mail threads and concerns can be discussed and in the worst case a change can be rejected entirely. For smaller changes everyone just sends patches to the list that are usually accepted and sometimes rejected if someone objects. For infrastructure changes, a patch review after it is done isn't possible. So these are more the big kind of changes that should be announced with at least a few days time for someone to object or discuss. Tickets are nice but they are not very visible. This list is open and public for the project and its community and I will not tolerant any commercial activity of any type. Sorry, shouldn't have mentioned "Someone wants to fund ...". The tickets already had something similar in the comments, so I didn't think that someone would object as long as it is an anonymous "Someone wants to fund ..." and not "Company X wants to fund ...". Regarding the tickets, there are many cases over the years of those providing services performing services internally, raising tickets and committing changes. I see no issue here and I am fine with that continuing to happen. Finally, my understanding of the funded tickets is most of the work is to rebuild the servers to be current and capable of running modern CI systems, what ever that ends up being. Maintenance tasks that keep the systems running are fine without an announcement. These are a lot of great work that happens behind the scenes. But these tasks don't change how a user can access the system. It's great if someone decides to make that work visible too so that everyone can at least say a "thank you", but it's not necessary. For tasks that change something fundamental, some public review time would be nice at least a few days before the work starts. Like said above: I would see that similar to review time for every patch that is more or less a suggestion to change something. I haven't seen that announcement and review time for the tickets that are already funded. Maybe I missed it and if that is the case it's fully my fault and I'm sorry that I even started the discussion. On the other hand all currently funded tickets fall into the category "necessary maintenance task" so I clearly overreacted to even mention it. Regarding the commercial aspect: Of course an announcement doesn't have to happen before a contract is closed - that is something between the two companies or individuals that close the contract. But like you said multiple times yourself: It's not a contract that the RTEMS project closes but one between two unrelated legal entities. So it's still possible that a community members might object and in the worst case block the change. Just to make that clear again: Except for some details (that we are currently discussing in various mail threads) I'm
Re: GitLab and BuildBot
On 8/2/2023 8:04 pm, Christian MAUDERER wrote: > On 2023-02-07 23:37, Chris Johns wrote: >> On 7/2/2023 9:31 pm, Christian MAUDERER wrote: >>> On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: >>> That shouldn't be a pure decision by the one who pays for the work but one >>> that >>> is (in the optimal case) discussed and specified in the tickets. >> >> I did not know that was happening. I am sorry if you think it is and if I >> gave >> you that impression. > > There have been relatively new tickets that changed the status from > "needs-funding" to "funded" nearly without delay. That was a bit surprising > for me. > > It seems that the tickets are still updated based on feedback so that is fine > and it's great that someone funded them. It just would have been nice if there > would have been some announcement for two or three days like "Someone wants to > fund the tickets 1, 2 and that part of 4 exactly like they are written now. If > there are big objections with the direction, please speak up now." I have never seen EB, your employer, make such an announcement about private commercial in confidence contracts in this way and I would never expect EB to do that so I think it is outrageous you think you can ask this here like this. The funding is a private commercial agreement Amar has and it is no different to the ones your employer makes. Any questions need to be directed to Amar directly but I suggest the questions should be along of the lines of what you can fund. This list is open and public for the project and its community and I will not tolerant any commercial activity of any type. Regarding the tickets, there are many cases over the years of those providing services performing services internally, raising tickets and committing changes. I see no issue here and I am fine with that continuing to happen. Finally, my understanding of the funded tickets is most of the work is to rebuild the servers to be current and capable of running modern CI systems, what ever that ends up being. > At the moment I don't need all tickets from my point of view. But there are no > tickets that I would see as a problem. So again: I'm happy that our system > will > get better. Thank you the positive feed back, it is appreciated. The process is not perfect and what can be achieved is limited but things are moving and changing and that is encouraging. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GitLab and BuildBot
On 2023-02-07 23:37, Chris Johns wrote: On 7/2/2023 9:31 pm, Christian MAUDERER wrote: On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: Hello, recently the following tickets were added (beneath a few more related ones): https://devel.rtems.org/ticket/4790 - Setup Gitlab instance https://devel.rtems.org/ticket/4791 - Update BuildBot It's great that a patch review system and a CI/CD that builds every patch for RTEMS starts to get within reach. Thanks a lot to all involved in that for the efforts. It is exciting to see this happening. It will benefit the project and all who give their time. I reviewed earlier discussions related to CI/CD. From my point of view there are mainly two points that are missing in the tickets: First: From my point of view, we should make it simple for new users to register. Adding authentication using well-known services can help with that. GitLab supports (for example): - GitHub: https://docs.gitlab.com/ee/integration/github.html - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html - Google: https://docs.gitlab.com/ee/integration/google.html - ... I think it would be good to select the most common ones (at least the three mentioned above) and add them as a goal to the ticket or a new one. What do you think? I suggest a ticket to handle authentication. If you create a ticket please indicate it is unfunded. If this is handled else where and in another ticket this one can be closed with a suitable reason. https://devel.rtems.org/ticket/4840 Thanks. The addition of these authentication methods can be done when someone funds the work. If a person or organisation thinks it is important please reach out to Amar directly. Second: It's still a bit unclear for me how the CI/CD with BuildBot will work. Will it be possible for anyone to help improve the CI/CD? An example to make it clear what I want to know: Let's assume an unprivileged developer has a patch set that allows building device tree files using the RTEMS build system, but the patches require a new tool like dtc. Let's further assume that the idea has been discussed and everyone agrees that it is a good idea (currently not yet the case for dtc). Problem is: The patches trigger a CI error because the new tool is missing and therefore can't be merged yet. How can the developer suggest a fix so that the patches can be accepted faster without having to wait for one specific maintainer to have enough time for adapting the CI config? There are details that will need to be worked out. Deployment of tools for building in a CI flow is important. How complex and automated this will be will depends on the funding provided. At this point in time the push is to get a basic framework up that allows us to handle simple merge requests. The approach is more organic in nature so funding can be targeted at the most important foundation pieces. Further funding can build on that base. Before we get to Gitlab and CI we need to rebase the servers and software on them. This part of the effort is funded and under way. Amar is updating the tickets with the progress. Maybe my question hasn't been clear enough. Of course part of it depends on what is implemented. But every selected system also adds limitations. At the moment BuildBot is the suggested system in the tickets. It is a well known service and has a lot of usefull features for us that certainly make it a good choice. But I never really worked with it, so I basically wanted to know what I have to expect. Some systems like (I think it was) jenkins.io can be configured to behave quite different depending on how you use it. You can either configure it via a static configuration that is put somewhere where only admins can access it. But you can also configure it in a way that build jobs are defined by yaml files in the repository similar to popular services like GitHub, GitLab or Travis. Basically what I wanted to know is: What is possible / usual with BuildBot and which of the possible solutions do we want to use? A developer with a gitlab account will be encouraged to move their personal repo to their gitlab account and doing that allows them to use the gitlab CI tools. Gitlab will be running on FreeBSD and in a jail so any dependent services a developer needs will need to be requested via a ticket. I hope you appreciate there are limit here related to resources and the hardened nature of the environment. Of course there are limits. That's OK. Do we configure BuildBot statically and every change will be done only if someone pays for it? The main CI build flows will be controlled and changed via a ticket. We need to QA control that process to ensure the patches merged are suitable. I have no idea yet how this will look and work but it will need to allow the project to make updates. Wether this is widely available on the first pass or pass ten of the work that needs to be done I cannot say. Of
Re: GitLab and BuildBot
On 7/2/2023 9:31 pm, Christian MAUDERER wrote: > On 2023-02-07 07:03, Chris Johns wrote: >> On 30/1/2023 10:12 pm, Christian MAUDERER wrote: >>> Hello, >>> >>> recently the following tickets were added (beneath a few more related ones): >>> >>> https://devel.rtems.org/ticket/4790 - Setup Gitlab instance >>> https://devel.rtems.org/ticket/4791 - Update BuildBot >>> >>> It's great that a patch review system and a CI/CD that builds every patch >>> for >>> RTEMS starts to get within reach. Thanks a lot to all involved in that for >>> the >>> efforts. >> >> It is exciting to see this happening. It will benefit the project and all who >> give their time. >> >>> I reviewed earlier discussions related to CI/CD. From my point of view >>> there are >>> mainly two points that are missing in the tickets: >>> >>> First: From my point of view, we should make it simple for new users to >>> register. Adding authentication using well-known services can help with >>> that. >>> GitLab supports (for example): >>> - GitHub: https://docs.gitlab.com/ee/integration/github.html >>> - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html >>> - Google: https://docs.gitlab.com/ee/integration/google.html >>> - ... >>> I think it would be good to select the most common ones (at least the three >>> mentioned above) and add them as a goal to the ticket or a new one. What do >>> you >>> think? >> >> I suggest a ticket to handle authentication. If you create a ticket please >> indicate it is unfunded. If this is handled else where and in another ticket >> this one can be closed with a suitable reason. >> > > https://devel.rtems.org/ticket/4840 Thanks. >> The addition of these authentication methods can be done when someone funds >> the >> work. If a person or organisation thinks it is important please reach out to >> Amar directly. >> >>> Second: It's still a bit unclear for me how the CI/CD with BuildBot will >>> work. >>> Will it be possible for anyone to help improve the CI/CD? An example to >>> make it >>> clear what I want to know: Let's assume an unprivileged developer has a >>> patch >>> set that allows building device tree files using the RTEMS build system, >>> but the >>> patches require a new tool like dtc. Let's further assume that the idea has >>> been >>> discussed and everyone agrees that it is a good idea (currently not yet the >>> case >>> for dtc). Problem is: The patches trigger a CI error because the new tool is >>> missing and therefore can't be merged yet. How can the developer suggest a >>> fix >>> so that the patches can be accepted faster without having to wait for one >>> specific maintainer to have enough time for adapting the CI config? >> >> There are details that will need to be worked out. Deployment of tools for >> building in a CI flow is important. How complex and automated this will be >> will >> depends on the funding provided. At this point in time the push is to get a >> basic framework up that allows us to handle simple merge requests. The >> approach >> is more organic in nature so funding can be targeted at the most important >> foundation pieces. Further funding can build on that base. Before we get to >> Gitlab and CI we need to rebase the servers and software on them. This part >> of >> the effort is funded and under way. Amar is updating the tickets with the >> progress. > > Maybe my question hasn't been clear enough. Of course part of it depends on > what > is implemented. But every selected system also adds limitations. At the moment > BuildBot is the suggested system in the tickets. It is a well known service > and > has a lot of usefull features for us that certainly make it a good choice. > > But I never really worked with it, so I basically wanted to know what I have > to > expect. Some systems like (I think it was) jenkins.io can be configured to > behave quite different depending on how you use it. You can either configure > it > via a static configuration that is put somewhere where only admins can access > it. But you can also configure it in a way that build jobs are defined by yaml > files in the repository similar to popular services like GitHub, GitLab or > Travis. > > Basically what I wanted to know is: What is possible / usual with BuildBot and > which of the possible solutions do we want to use? A developer with a gitlab account will be encouraged to move their personal repo to their gitlab account and doing that allows them to use the gitlab CI tools. Gitlab will be running on FreeBSD and in a jail so any dependent services a developer needs will need to be requested via a ticket. I hope you appreciate there are limit here related to resources and the hardened nature of the environment. > Do we configure BuildBot > statically and every change will be done only if someone pays for it? The main CI build flows will be controlled and changed via a ticket. We need to QA control that process to ensure the patches merged are
Re: GitLab and BuildBot
On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: Hello, recently the following tickets were added (beneath a few more related ones): https://devel.rtems.org/ticket/4790 - Setup Gitlab instance https://devel.rtems.org/ticket/4791 - Update BuildBot It's great that a patch review system and a CI/CD that builds every patch for RTEMS starts to get within reach. Thanks a lot to all involved in that for the efforts. It is exciting to see this happening. It will benefit the project and all who give their time. I reviewed earlier discussions related to CI/CD. From my point of view there are mainly two points that are missing in the tickets: First: From my point of view, we should make it simple for new users to register. Adding authentication using well-known services can help with that. GitLab supports (for example): - GitHub: https://docs.gitlab.com/ee/integration/github.html - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html - Google: https://docs.gitlab.com/ee/integration/google.html - ... I think it would be good to select the most common ones (at least the three mentioned above) and add them as a goal to the ticket or a new one. What do you think? I suggest a ticket to handle authentication. If you create a ticket please indicate it is unfunded. If this is handled else where and in another ticket this one can be closed with a suitable reason. https://devel.rtems.org/ticket/4840 The addition of these authentication methods can be done when someone funds the work. If a person or organisation thinks it is important please reach out to Amar directly. Second: It's still a bit unclear for me how the CI/CD with BuildBot will work. Will it be possible for anyone to help improve the CI/CD? An example to make it clear what I want to know: Let's assume an unprivileged developer has a patch set that allows building device tree files using the RTEMS build system, but the patches require a new tool like dtc. Let's further assume that the idea has been discussed and everyone agrees that it is a good idea (currently not yet the case for dtc). Problem is: The patches trigger a CI error because the new tool is missing and therefore can't be merged yet. How can the developer suggest a fix so that the patches can be accepted faster without having to wait for one specific maintainer to have enough time for adapting the CI config? There are details that will need to be worked out. Deployment of tools for building in a CI flow is important. How complex and automated this will be will depends on the funding provided. At this point in time the push is to get a basic framework up that allows us to handle simple merge requests. The approach is more organic in nature so funding can be targeted at the most important foundation pieces. Further funding can build on that base. Before we get to Gitlab and CI we need to rebase the servers and software on them. This part of the effort is funded and under way. Amar is updating the tickets with the progress. Maybe my question hasn't been clear enough. Of course part of it depends on what is implemented. But every selected system also adds limitations. At the moment BuildBot is the suggested system in the tickets. It is a well known service and has a lot of usefull features for us that certainly make it a good choice. But I never really worked with it, so I basically wanted to know what I have to expect. Some systems like (I think it was) jenkins.io can be configured to behave quite different depending on how you use it. You can either configure it via a static configuration that is put somewhere where only admins can access it. But you can also configure it in a way that build jobs are defined by yaml files in the repository similar to popular services like GitHub, GitLab or Travis. Basically what I wanted to know is: What is possible / usual with BuildBot and which of the possible solutions do we want to use? Do we configure BuildBot statically and every change will be done only if someone pays for it? Will there be a repo with config files where everyone can suggest and help but only one or two admins can accept changes if they have time? Or will every repo contain a config yaml (or similar format) and every maintainer can accept a change to that? Or is the currently discussed solution something completely different? That shouldn't be a pure decision by the one who pays for the work but one that is (in the optimal case) discussed and specified in the tickets. That way everyone in the community has at least a chance to have some influence on the system that he will have to use later. Best regards Christian The hope is gitlab admin activities can be shared. Amar and I have briefly discussed this but nothing has been decided. We need a gitleb instance before this becomes something we need to handle. Chris -- embedded brains
Re: GitLab and BuildBot
On 30/1/2023 10:12 pm, Christian MAUDERER wrote: > Hello, > > recently the following tickets were added (beneath a few more related ones): > > https://devel.rtems.org/ticket/4790 - Setup Gitlab instance > https://devel.rtems.org/ticket/4791 - Update BuildBot > > It's great that a patch review system and a CI/CD that builds every patch for > RTEMS starts to get within reach. Thanks a lot to all involved in that for the > efforts. It is exciting to see this happening. It will benefit the project and all who give their time. > I reviewed earlier discussions related to CI/CD. From my point of view there > are > mainly two points that are missing in the tickets: > > First: From my point of view, we should make it simple for new users to > register. Adding authentication using well-known services can help with that. > GitLab supports (for example): > - GitHub: https://docs.gitlab.com/ee/integration/github.html > - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html > - Google: https://docs.gitlab.com/ee/integration/google.html > - ... > I think it would be good to select the most common ones (at least the three > mentioned above) and add them as a goal to the ticket or a new one. What do > you > think? I suggest a ticket to handle authentication. If you create a ticket please indicate it is unfunded. If this is handled else where and in another ticket this one can be closed with a suitable reason. The addition of these authentication methods can be done when someone funds the work. If a person or organisation thinks it is important please reach out to Amar directly. > Second: It's still a bit unclear for me how the CI/CD with BuildBot will work. > Will it be possible for anyone to help improve the CI/CD? An example to make > it > clear what I want to know: Let's assume an unprivileged developer has a patch > set that allows building device tree files using the RTEMS build system, but > the > patches require a new tool like dtc. Let's further assume that the idea has > been > discussed and everyone agrees that it is a good idea (currently not yet the > case > for dtc). Problem is: The patches trigger a CI error because the new tool is > missing and therefore can't be merged yet. How can the developer suggest a fix > so that the patches can be accepted faster without having to wait for one > specific maintainer to have enough time for adapting the CI config? There are details that will need to be worked out. Deployment of tools for building in a CI flow is important. How complex and automated this will be will depends on the funding provided. At this point in time the push is to get a basic framework up that allows us to handle simple merge requests. The approach is more organic in nature so funding can be targeted at the most important foundation pieces. Further funding can build on that base. Before we get to Gitlab and CI we need to rebase the servers and software on them. This part of the effort is funded and under way. Amar is updating the tickets with the progress. The hope is gitlab admin activities can be shared. Amar and I have briefly discussed this but nothing has been decided. We need a gitleb instance before this becomes something we need to handle. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GitLab and BuildBot
Hello, recently the following tickets were added (beneath a few more related ones): https://devel.rtems.org/ticket/4790 - Setup Gitlab instance https://devel.rtems.org/ticket/4791 - Update BuildBot It's great that a patch review system and a CI/CD that builds every patch for RTEMS starts to get within reach. Thanks a lot to all involved in that for the efforts. I reviewed earlier discussions related to CI/CD. From my point of view there are mainly two points that are missing in the tickets: First: From my point of view, we should make it simple for new users to register. Adding authentication using well-known services can help with that. GitLab supports (for example): - GitHub: https://docs.gitlab.com/ee/integration/github.html - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html - Google: https://docs.gitlab.com/ee/integration/google.html - ... I think it would be good to select the most common ones (at least the three mentioned above) and add them as a goal to the ticket or a new one. What do you think? Second: It's still a bit unclear for me how the CI/CD with BuildBot will work. Will it be possible for anyone to help improve the CI/CD? An example to make it clear what I want to know: Let's assume an unprivileged developer has a patch set that allows building device tree files using the RTEMS build system, but the patches require a new tool like dtc. Let's further assume that the idea has been discussed and everyone agrees that it is a good idea (currently not yet the case for dtc). Problem is: The patches trigger a CI error because the new tool is missing and therefore can't be merged yet. How can the developer suggest a fix so that the patches can be accepted faster without having to wait for one specific maintainer to have enough time for adapting the CI config? Best regards Christian -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
