Zorg migration to GitHub/monorepo - Done
Hello everyone, Zorg migration to GitHub/monorepo is complete. I have removed the following builders from the production build bot: * clang-atom-d525-fedora-rel - fails to checkout from github * clang-x64-ninja-win7 - fails to checkout from github * polly-amd64-linux - missing git * llvm-hexagon-elf - does not support github The rest of the builders are working well. The whole production build bot is back to normal. Thank you for your patience and understanding. Please let me know if you see any issue with the build bot. Thanks Galina ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Zorg migration to GitHub/monorepo - Step 2
Hello everyone, As all of you know, the migration to github monorepo is done. The production master is currently working in a transition mode, when it supports both, bots already working with github, and bots still working with SVN. Today we will turn "github only" mode for the production master. Those builders which depend on ported build factories and were staged are good. The builders which depend on ported build factories and have not been staged might just work after this change. Those which turn red will be temporarily removed from the production master. If you are an owner of such builder, please feel free to stage it, make it green in staging, and then you could bring it to the production build bot. The builders which still require SVN to build will be removed form the production master. If you are an owner of such builder, please feel free to stage it, port it to work with the github monorepo, make it green, and then you could bring it to the production build bot. Here is the list of not yet staged builders of the last 2 kinds in the alphabetical order: aosp-O3-polly-before-vectorizer-unprofitable clang-aarch64-linux-build-cache clang-armv7-linux-build-cache clang-atom-d525-fedora-rel clang-cmake-x86_64-avx2-linux clang-cmake-x86_64-avx2-linux-perf clang-cmake-x86_64-sde-avx512-linux clang-cuda-build clang-hexagon-elf clang-s390x-linux clang-s390x-linux-lnt clang-s390x-linux-multistage clang-x64-ninja-win7 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu libcxx-libcxxabi-x86_64-linux-ubuntu-32bit libcxx-libcxxabi-x86_64-linux-ubuntu-asan libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std libcxx-libcxxabi-x86_64-linux-ubuntu-msan libcxx-libcxxabi-x86_64-linux-ubuntu-tsan libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan llvm-hexagon-elf polly-amd64-linux polly-arm-linux reverse-iteration Please let me know if you have any questions. Thank you for your patience and understanding. Galina ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [llvm-dev] Zorg migration to GitHub/monorepo
Thanks for explaining, Diana. And you are welcome. I’m glad this is not an issue with missing changes or something. Thanks Galina On Tue, Oct 29, 2019 at 1:48 AM Diana Picus wrote: > > Hi Galina, > > On Tue, 29 Oct 2019 at 04:42, Galina Kistanova wrote: > > > > Hello Nemanja, > > > > > a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. > > > the change was in llvm). > > > > With all due respect, this does not sound right. > > I'm not sure how changes in a code a particular bot builds and tests > > should not trigger builds. In many cases this will lead to false blame > > lists, which is very annoying for developers, and hurt a quality of a > > bot. Could somebody elaborate a valid use case for this, please? If > > this is what Diana meant, of course. > > Yes, this is what I meant. In the past, we only triggered builds for > commits to libcxx, libcxxabi and libunwind. E.g. > http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux/builds/1048 > > So I actually thought the bots were building without checking out > llvm. I now realize I was wrong and they did pull and build llvm as > well, so I guess the previous behaviour was buggy. Thanks for helping > us clarify this issue! > > Cheers, > Diana > > > > I have a somewhat orthogonal but related question. In the past, commits > > > to compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has > > > this behaviour been rectified with the move to github? > > > > Before the move we had a set of schedulers with manually specified > > list of projects to listen and assigned per group of bots. This was an > > error prone as people were adding bots without realizing that a group > > they add a bot to does not listen for a changes in some of the > > projects that particular bot depends on. You have mentioned an example > > of such issues. > > > > Now we use the dependency list for each of the monorepo-ready build > > factory (depends_on_projects param) to figure out what changes should > > trigger a build, as well as to configure the "-DLLVM_ENABLE_PROJECTS=" > > cmake arg. The dependency list could be redefined per builder, if for > > any reason a build factory default doesn't work well. All the > > schedulers are configured automatically and every bot is served with > > changes to any and all projects it claims a dependency on. This should > > give a better and transparent way to define and track what would and > > what would not trigger a build. This is the idea at least. Some work > > remains to be done as not all of the build factories let redefine the > > dependency list yet, not all set "-DLLVM_ENABLE_PROJECTS=" properly, > > and such. > > > > Thanks > > > > Galina > > > > On Mon, Oct 28, 2019 at 5:09 PM Nemanja Ivanovic > > wrote: > > > > > > I think what she is referring to was that the build seemed to be > > > triggered by a commit to a project that shouldn't trigger builds on a > > > libcxx bot (i.e. the change was in llvm). > > > > > > I have a somewhat orthogonal but related question. In the past, commits > > > to compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has > > > this behaviour been rectified with the move to github? I am really sorry > > > if you already answered this question and I just missed it. > > > > > > On Mon, Oct 28, 2019 at 2:37 PM Galina Kistanova via llvm-dev > > > wrote: > > >> > > >> Hi Diana, > > >> > > >> It is not clear from your description of what is the problem. Could > > >> you elaborate, please? > > >> > > >> I have looked at the build history closer and see that this build > > >> configuration depends on libcxx, libcxxabi, libunwind, llvm projects, > > >> and changes to any of these would trigger a build. Depending on a bot > > >> performance, patches could be grouped to a longer blame list. To me, > > >> this is exactly how it supposedly should be. Are you missing any > > >> particular changes in libcxx, libcxxabi,or libunwind project which > > >> should trigger a build but they didn't? If so, could you point me to > > >> such change, please? > > >> > > >> Thanks > > >> > > >> Galina > > >> > > >> > > >> > > >> On Mon, Oct 28, 2019 at 5:16 AM Diana Picus > > >> wrote: > > >> > > > >> > Hi Galina, > > >> > > > >> > It seems that our libcxx bots are now triggering builds for any > > >> > changes to llvm: > > >> > http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 > > >> > > > >> > Should I file a bug report for this? > > >> > > > >> > Thanks, > > >> > Diana > > >> > > > >> > On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits > > >> > wrote: > > >> > > > > >> > > Hello everyone, > > >> > > > > >> > > The staging master is ready to accept bots from the list I have sent > > >> > > yesterday. Don't wait too long. > > >> > > > > >> > > The master has been updated and works with both SVN and Github > > >> > > monorepo now. > > >> > > > > >> > > The following builders are already listening for
Re: [llvm-dev] Zorg migration to GitHub/monorepo
Hi Galina, On Tue, 29 Oct 2019 at 04:42, Galina Kistanova wrote: > > Hello Nemanja, > > > a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. > > the change was in llvm). > > With all due respect, this does not sound right. > I'm not sure how changes in a code a particular bot builds and tests > should not trigger builds. In many cases this will lead to false blame > lists, which is very annoying for developers, and hurt a quality of a > bot. Could somebody elaborate a valid use case for this, please? If > this is what Diana meant, of course. Yes, this is what I meant. In the past, we only triggered builds for commits to libcxx, libcxxabi and libunwind. E.g. http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux/builds/1048 So I actually thought the bots were building without checking out llvm. I now realize I was wrong and they did pull and build llvm as well, so I guess the previous behaviour was buggy. Thanks for helping us clarify this issue! Cheers, Diana > > I have a somewhat orthogonal but related question. In the past, commits to > > compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this > > behaviour been rectified with the move to github? > > Before the move we had a set of schedulers with manually specified > list of projects to listen and assigned per group of bots. This was an > error prone as people were adding bots without realizing that a group > they add a bot to does not listen for a changes in some of the > projects that particular bot depends on. You have mentioned an example > of such issues. > > Now we use the dependency list for each of the monorepo-ready build > factory (depends_on_projects param) to figure out what changes should > trigger a build, as well as to configure the "-DLLVM_ENABLE_PROJECTS=" > cmake arg. The dependency list could be redefined per builder, if for > any reason a build factory default doesn't work well. All the > schedulers are configured automatically and every bot is served with > changes to any and all projects it claims a dependency on. This should > give a better and transparent way to define and track what would and > what would not trigger a build. This is the idea at least. Some work > remains to be done as not all of the build factories let redefine the > dependency list yet, not all set "-DLLVM_ENABLE_PROJECTS=" properly, > and such. > > Thanks > > Galina > > On Mon, Oct 28, 2019 at 5:09 PM Nemanja Ivanovic > wrote: > > > > I think what she is referring to was that the build seemed to be triggered > > by a commit to a project that shouldn't trigger builds on a libcxx bot > > (i.e. the change was in llvm). > > > > I have a somewhat orthogonal but related question. In the past, commits to > > compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this > > behaviour been rectified with the move to github? I am really sorry if you > > already answered this question and I just missed it. > > > > On Mon, Oct 28, 2019 at 2:37 PM Galina Kistanova via llvm-dev > > wrote: > >> > >> Hi Diana, > >> > >> It is not clear from your description of what is the problem. Could > >> you elaborate, please? > >> > >> I have looked at the build history closer and see that this build > >> configuration depends on libcxx, libcxxabi, libunwind, llvm projects, > >> and changes to any of these would trigger a build. Depending on a bot > >> performance, patches could be grouped to a longer blame list. To me, > >> this is exactly how it supposedly should be. Are you missing any > >> particular changes in libcxx, libcxxabi,or libunwind project which > >> should trigger a build but they didn't? If so, could you point me to > >> such change, please? > >> > >> Thanks > >> > >> Galina > >> > >> > >> > >> On Mon, Oct 28, 2019 at 5:16 AM Diana Picus wrote: > >> > > >> > Hi Galina, > >> > > >> > It seems that our libcxx bots are now triggering builds for any changes > >> > to llvm: > >> > http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 > >> > > >> > Should I file a bug report for this? > >> > > >> > Thanks, > >> > Diana > >> > > >> > On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits > >> > wrote: > >> > > > >> > > Hello everyone, > >> > > > >> > > The staging master is ready to accept bots from the list I have sent > >> > > yesterday. Don't wait too long. > >> > > > >> > > The master has been updated and works with both SVN and Github > >> > > monorepo now. > >> > > > >> > > The following builders are already listening for changes in monorepo > >> > > and building monorepo. More are coming. > >> > > > >> > > * clang-sphinx-docs > >> > > * clang-tools-sphinx-docs > >> > > * clang-x86_64-linux-abi-test > >> > > * clang-lld-x86_64-2stage > >> > > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > >> > > * libcxx-sphinx-docs > >> > > * libunwind-sphinx-docs > >> > > * lld-sphinx-docs > >> > > * lld-x86_64-darwin13 > >> > > *
Re: [llvm-dev] Zorg migration to GitHub/monorepo
Hello Nemanja, > a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. the > change was in llvm). With all due respect, this does not sound right. I'm not sure how changes in a code a particular bot builds and tests should not trigger builds. In many cases this will lead to false blame lists, which is very annoying for developers, and hurt a quality of a bot. Could somebody elaborate a valid use case for this, please? If this is what Diana meant, of course. > I have a somewhat orthogonal but related question. In the past, commits to > compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this > behaviour been rectified with the move to github? Before the move we had a set of schedulers with manually specified list of projects to listen and assigned per group of bots. This was an error prone as people were adding bots without realizing that a group they add a bot to does not listen for a changes in some of the projects that particular bot depends on. You have mentioned an example of such issues. Now we use the dependency list for each of the monorepo-ready build factory (depends_on_projects param) to figure out what changes should trigger a build, as well as to configure the "-DLLVM_ENABLE_PROJECTS=" cmake arg. The dependency list could be redefined per builder, if for any reason a build factory default doesn't work well. All the schedulers are configured automatically and every bot is served with changes to any and all projects it claims a dependency on. This should give a better and transparent way to define and track what would and what would not trigger a build. This is the idea at least. Some work remains to be done as not all of the build factories let redefine the dependency list yet, not all set "-DLLVM_ENABLE_PROJECTS=" properly, and such. Thanks Galina On Mon, Oct 28, 2019 at 5:09 PM Nemanja Ivanovic wrote: > > I think what she is referring to was that the build seemed to be triggered by > a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. the > change was in llvm). > > I have a somewhat orthogonal but related question. In the past, commits to > compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this > behaviour been rectified with the move to github? I am really sorry if you > already answered this question and I just missed it. > > On Mon, Oct 28, 2019 at 2:37 PM Galina Kistanova via llvm-dev > wrote: >> >> Hi Diana, >> >> It is not clear from your description of what is the problem. Could >> you elaborate, please? >> >> I have looked at the build history closer and see that this build >> configuration depends on libcxx, libcxxabi, libunwind, llvm projects, >> and changes to any of these would trigger a build. Depending on a bot >> performance, patches could be grouped to a longer blame list. To me, >> this is exactly how it supposedly should be. Are you missing any >> particular changes in libcxx, libcxxabi,or libunwind project which >> should trigger a build but they didn't? If so, could you point me to >> such change, please? >> >> Thanks >> >> Galina >> >> >> >> On Mon, Oct 28, 2019 at 5:16 AM Diana Picus wrote: >> > >> > Hi Galina, >> > >> > It seems that our libcxx bots are now triggering builds for any changes to >> > llvm: >> > http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 >> > >> > Should I file a bug report for this? >> > >> > Thanks, >> > Diana >> > >> > On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits >> > wrote: >> > > >> > > Hello everyone, >> > > >> > > The staging master is ready to accept bots from the list I have sent >> > > yesterday. Don't wait too long. >> > > >> > > The master has been updated and works with both SVN and Github monorepo >> > > now. >> > > >> > > The following builders are already listening for changes in monorepo and >> > > building monorepo. More are coming. >> > > >> > > * clang-sphinx-docs >> > > * clang-tools-sphinx-docs >> > > * clang-x86_64-linux-abi-test >> > > * clang-lld-x86_64-2stage >> > > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian >> > > * libcxx-sphinx-docs >> > > * libunwind-sphinx-docs >> > > * lld-sphinx-docs >> > > * lld-x86_64-darwin13 >> > > * lld-x86_64-ubuntu-fast >> > > * lldb-sphinx-docs >> > > * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast >> > > * llvm-clang-x86_64-win-fast <<-- ? >> > > * llvm-sphinx-docs >> > > * clang-x86_64-debian-fast >> > > * libcxx-libcxxabi-libunwind-x86_64-linux-debian >> > > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian >> > > * libcxx-libcxxabi-x86_64-linux-debian >> > > * libcxx-libcxxabi-x86_64-linux-debian-noexceptions >> > > >> > > A friendly reminder. If your bots are using one of these build >> > > factories, you would need either update your build configurations to use >> > > one of the currently supported build factories, or port that factory to >> > > work with github and monorepo. >> > > >> > > * LLVMBuilder (3 bots) >> >
Re: [llvm-dev] Zorg migration to GitHub/monorepo
I think what she is referring to was that the build seemed to be triggered by a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. the change was in llvm). I have a somewhat orthogonal but related question. In the past, commits to compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this behaviour been rectified with the move to github? I am really sorry if you already answered this question and I just missed it. On Mon, Oct 28, 2019 at 2:37 PM Galina Kistanova via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hi Diana, > > It is not clear from your description of what is the problem. Could > you elaborate, please? > > I have looked at the build history closer and see that this build > configuration depends on libcxx, libcxxabi, libunwind, llvm projects, > and changes to any of these would trigger a build. Depending on a bot > performance, patches could be grouped to a longer blame list. To me, > this is exactly how it supposedly should be. Are you missing any > particular changes in libcxx, libcxxabi,or libunwind project which > should trigger a build but they didn't? If so, could you point me to > such change, please? > > Thanks > > Galina > > > > On Mon, Oct 28, 2019 at 5:16 AM Diana Picus > wrote: > > > > Hi Galina, > > > > It seems that our libcxx bots are now triggering builds for any changes > to llvm: > > > http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 > > > > Should I file a bug report for this? > > > > Thanks, > > Diana > > > > On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits > > wrote: > > > > > > Hello everyone, > > > > > > The staging master is ready to accept bots from the list I have sent > yesterday. Don't wait too long. > > > > > > The master has been updated and works with both SVN and Github > monorepo now. > > > > > > The following builders are already listening for changes in monorepo > and building monorepo. More are coming. > > > > > > * clang-sphinx-docs > > > * clang-tools-sphinx-docs > > > * clang-x86_64-linux-abi-test > > > * clang-lld-x86_64-2stage > > > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > > > * libcxx-sphinx-docs > > > * libunwind-sphinx-docs > > > * lld-sphinx-docs > > > * lld-x86_64-darwin13 > > > * lld-x86_64-ubuntu-fast > > > * lldb-sphinx-docs > > > * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast > > > * llvm-clang-x86_64-win-fast <<-- ? > > > * llvm-sphinx-docs > > > * clang-x86_64-debian-fast > > > * libcxx-libcxxabi-libunwind-x86_64-linux-debian > > > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > > > * libcxx-libcxxabi-x86_64-linux-debian > > > * libcxx-libcxxabi-x86_64-linux-debian-noexceptions > > > > > > A friendly reminder. If your bots are using one of these build > factories, you would need either update your build configurations to use > one of the currently supported build factories, or port that factory to > work with github and monorepo. > > > > > > * LLVMBuilder (3 bots) > > > * PollyBuilder (3 bots) > > > * LLDBBuilder (6 bots) > > > * SanitizerBuilder (10 bots) > > > * CUDATestsuiteBuilder (1 bot) - depends on > ClangBuilder.getClangBuildFactory > > > * AOSPBuilder (1 bot) - depends on PollyBuilder > > > * AnnotatedBuilder (2 bots) > > > * OpenMPBuilder (2 bots) > > > * FuchsiaBuilder (1 bot) > > > > > > Thanks > > > > > > Galina > > > > > > > > > On Fri, Oct 18, 2019 at 12:05 AM Galina Kistanova < > gkistan...@gmail.com> wrote: > > >> > > >> Hello build bot owners! > > >> > > >> The staging master is ready. Please feel free to use it to make sure > your bots would work well with the monorepo and github. > > >> > > >> The following builders could be configured to build monorepo: > > >> > > >> * clang-atom-d525-fedora-rel > > >> * clang-native-arm-lnt-perf > > >> * clang-cmake-armv7-lnt > > >> * clang-cmake-armv7-selfhost-neon > > >> * clang-cmake-armv7-quick > > >> * clang-cmake-armv7-global-isel > > >> * clang-cmake-armv7-selfhost > > >> * clang-cmake-aarch64-quick > > >> * clang-cmake-aarch64-lld > > >> * clang-cmake-aarch64-global-isel > > >> * clang-ppc64be-linux-lnt > > >> * clang-ppc64be-linux-multistage > > >> * clang-ppc64le-linux-lnt > > >> * clang-ppc64le-linux-multistage > > >> * clang-ppc64be-linux > > >> * clang-ppc64le-linux > > >> * clang-s390x-linux > > >> * clang-s390x-linux-multistage > > >> * clang-s390x-linux-lnt > > >> * clang-hexagon-elf > > >> * clang-cmake-x86_64-avx2-linux > > >> * clang-cmake-x86_64-avx2-linux-perf > > >> * clang-cmake-x86_64-sde-avx512-linux > > >> * clang-solaris11-amd64 > > >> * clang-x64-ninja-win7 > > >> * clang-solaris11-sparcv9 > > >> * clang-cmake-armv7-full > > >> * clang-cmake-thumbv7-full-sh > > >> * clang-cmake-armv8-lld > > >> * clang-cmake-aarch64-full > > >> * clang-armv7-linux-build-cache > > >> * clang-aarch64-linux-build-cache > > >> * libcxx-libcxxabi-x86_64-linux-debian > > >> * libcxx-libcxxabi-x86_64-linux-debian-noexceptions > > >> *
Re: Zorg migration to GitHub/monorepo
Hi Diana, It is not clear from your description of what is the problem. Could you elaborate, please? I have looked at the build history closer and see that this build configuration depends on libcxx, libcxxabi, libunwind, llvm projects, and changes to any of these would trigger a build. Depending on a bot performance, patches could be grouped to a longer blame list. To me, this is exactly how it supposedly should be. Are you missing any particular changes in libcxx, libcxxabi,or libunwind project which should trigger a build but they didn't? If so, could you point me to such change, please? Thanks Galina On Mon, Oct 28, 2019 at 5:16 AM Diana Picus wrote: > > Hi Galina, > > It seems that our libcxx bots are now triggering builds for any changes to > llvm: > http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 > > Should I file a bug report for this? > > Thanks, > Diana > > On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits > wrote: > > > > Hello everyone, > > > > The staging master is ready to accept bots from the list I have sent > > yesterday. Don't wait too long. > > > > The master has been updated and works with both SVN and Github monorepo now. > > > > The following builders are already listening for changes in monorepo and > > building monorepo. More are coming. > > > > * clang-sphinx-docs > > * clang-tools-sphinx-docs > > * clang-x86_64-linux-abi-test > > * clang-lld-x86_64-2stage > > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > > * libcxx-sphinx-docs > > * libunwind-sphinx-docs > > * lld-sphinx-docs > > * lld-x86_64-darwin13 > > * lld-x86_64-ubuntu-fast > > * lldb-sphinx-docs > > * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast > > * llvm-clang-x86_64-win-fast <<-- ? > > * llvm-sphinx-docs > > * clang-x86_64-debian-fast > > * libcxx-libcxxabi-libunwind-x86_64-linux-debian > > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > > * libcxx-libcxxabi-x86_64-linux-debian > > * libcxx-libcxxabi-x86_64-linux-debian-noexceptions > > > > A friendly reminder. If your bots are using one of these build factories, > > you would need either update your build configurations to use one of the > > currently supported build factories, or port that factory to work with > > github and monorepo. > > > > * LLVMBuilder (3 bots) > > * PollyBuilder (3 bots) > > * LLDBBuilder (6 bots) > > * SanitizerBuilder (10 bots) > > * CUDATestsuiteBuilder (1 bot) - depends on > > ClangBuilder.getClangBuildFactory > > * AOSPBuilder (1 bot) - depends on PollyBuilder > > * AnnotatedBuilder (2 bots) > > * OpenMPBuilder (2 bots) > > * FuchsiaBuilder (1 bot) > > > > Thanks > > > > Galina > > > > > > On Fri, Oct 18, 2019 at 12:05 AM Galina Kistanova > > wrote: > >> > >> Hello build bot owners! > >> > >> The staging master is ready. Please feel free to use it to make sure your > >> bots would work well with the monorepo and github. > >> > >> The following builders could be configured to build monorepo: > >> > >> * clang-atom-d525-fedora-rel > >> * clang-native-arm-lnt-perf > >> * clang-cmake-armv7-lnt > >> * clang-cmake-armv7-selfhost-neon > >> * clang-cmake-armv7-quick > >> * clang-cmake-armv7-global-isel > >> * clang-cmake-armv7-selfhost > >> * clang-cmake-aarch64-quick > >> * clang-cmake-aarch64-lld > >> * clang-cmake-aarch64-global-isel > >> * clang-ppc64be-linux-lnt > >> * clang-ppc64be-linux-multistage > >> * clang-ppc64le-linux-lnt > >> * clang-ppc64le-linux-multistage > >> * clang-ppc64be-linux > >> * clang-ppc64le-linux > >> * clang-s390x-linux > >> * clang-s390x-linux-multistage > >> * clang-s390x-linux-lnt > >> * clang-hexagon-elf > >> * clang-cmake-x86_64-avx2-linux > >> * clang-cmake-x86_64-avx2-linux-perf > >> * clang-cmake-x86_64-sde-avx512-linux > >> * clang-solaris11-amd64 > >> * clang-x64-ninja-win7 > >> * clang-solaris11-sparcv9 > >> * clang-cmake-armv7-full > >> * clang-cmake-thumbv7-full-sh > >> * clang-cmake-armv8-lld > >> * clang-cmake-aarch64-full > >> * clang-armv7-linux-build-cache > >> * clang-aarch64-linux-build-cache > >> * libcxx-libcxxabi-x86_64-linux-debian > >> * libcxx-libcxxabi-x86_64-linux-debian-noexceptions > >> * libcxx-libcxxabi-libunwind-x86_64-linux-debian > >> * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17 > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-32bit > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-asan > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-msan > >> * libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-tsan > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11 > >> * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std > >> * libcxx-libcxxabi-libunwind-armv7-linux > >> *
Re: Zorg migration to GitHub/monorepo
Hi Galina, It seems that our libcxx bots are now triggering builds for any changes to llvm: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 Should I file a bug report for this? Thanks, Diana On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits wrote: > > Hello everyone, > > The staging master is ready to accept bots from the list I have sent > yesterday. Don't wait too long. > > The master has been updated and works with both SVN and Github monorepo now. > > The following builders are already listening for changes in monorepo and > building monorepo. More are coming. > > * clang-sphinx-docs > * clang-tools-sphinx-docs > * clang-x86_64-linux-abi-test > * clang-lld-x86_64-2stage > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > * libcxx-sphinx-docs > * libunwind-sphinx-docs > * lld-sphinx-docs > * lld-x86_64-darwin13 > * lld-x86_64-ubuntu-fast > * lldb-sphinx-docs > * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast > * llvm-clang-x86_64-win-fast <<-- ? > * llvm-sphinx-docs > * clang-x86_64-debian-fast > * libcxx-libcxxabi-libunwind-x86_64-linux-debian > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > * libcxx-libcxxabi-x86_64-linux-debian > * libcxx-libcxxabi-x86_64-linux-debian-noexceptions > > A friendly reminder. If your bots are using one of these build factories, you > would need either update your build configurations to use one of the > currently supported build factories, or port that factory to work with github > and monorepo. > > * LLVMBuilder (3 bots) > * PollyBuilder (3 bots) > * LLDBBuilder (6 bots) > * SanitizerBuilder (10 bots) > * CUDATestsuiteBuilder (1 bot) - depends on ClangBuilder.getClangBuildFactory > * AOSPBuilder (1 bot) - depends on PollyBuilder > * AnnotatedBuilder (2 bots) > * OpenMPBuilder (2 bots) > * FuchsiaBuilder (1 bot) > > Thanks > > Galina > > > On Fri, Oct 18, 2019 at 12:05 AM Galina Kistanova > wrote: >> >> Hello build bot owners! >> >> The staging master is ready. Please feel free to use it to make sure your >> bots would work well with the monorepo and github. >> >> The following builders could be configured to build monorepo: >> >> * clang-atom-d525-fedora-rel >> * clang-native-arm-lnt-perf >> * clang-cmake-armv7-lnt >> * clang-cmake-armv7-selfhost-neon >> * clang-cmake-armv7-quick >> * clang-cmake-armv7-global-isel >> * clang-cmake-armv7-selfhost >> * clang-cmake-aarch64-quick >> * clang-cmake-aarch64-lld >> * clang-cmake-aarch64-global-isel >> * clang-ppc64be-linux-lnt >> * clang-ppc64be-linux-multistage >> * clang-ppc64le-linux-lnt >> * clang-ppc64le-linux-multistage >> * clang-ppc64be-linux >> * clang-ppc64le-linux >> * clang-s390x-linux >> * clang-s390x-linux-multistage >> * clang-s390x-linux-lnt >> * clang-hexagon-elf >> * clang-cmake-x86_64-avx2-linux >> * clang-cmake-x86_64-avx2-linux-perf >> * clang-cmake-x86_64-sde-avx512-linux >> * clang-solaris11-amd64 >> * clang-x64-ninja-win7 >> * clang-solaris11-sparcv9 >> * clang-cmake-armv7-full >> * clang-cmake-thumbv7-full-sh >> * clang-cmake-armv8-lld >> * clang-cmake-aarch64-full >> * clang-armv7-linux-build-cache >> * clang-aarch64-linux-build-cache >> * libcxx-libcxxabi-x86_64-linux-debian >> * libcxx-libcxxabi-x86_64-linux-debian-noexceptions >> * libcxx-libcxxabi-libunwind-x86_64-linux-debian >> * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17 >> * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a >> * libcxx-libcxxabi-x86_64-linux-ubuntu-32bit >> * libcxx-libcxxabi-x86_64-linux-ubuntu-asan >> * libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan >> * libcxx-libcxxabi-x86_64-linux-ubuntu-msan >> * libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu >> * libcxx-libcxxabi-x86_64-linux-ubuntu-tsan >> * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11 >> * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std >> * libcxx-libcxxabi-libunwind-armv7-linux >> * libcxx-libcxxabi-libunwind-armv8-linux >> * libcxx-libcxxabi-libunwind-armv7-linux-noexceptions >> * libcxx-libcxxabi-libunwind-armv8-linux-noexceptions >> * libcxx-libcxxabi-libunwind-aarch64-linux >> * libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions >> * ppc64le-lld-multistage-test >> >> These builders are already on the staging master. So, please ping me if you >> would like to configure any of them to work with monorepo: >> >> * clang-freebsd11-amd64 >> >> These builders have been already tested and could be reconfigured without >> staging as soon as public master is ready: >> >> * llvm-sphinx-docs >> * clang-sphinx-docs >> * clang-tools-sphinx-docs >> * lld-sphinx-docs >> * lldb-sphinx-docs >> * libcxx-sphinx-docs >> * libunwind-sphinx-docs >> * clang-x86_64-debian-fast >> * libcxx-libcxxabi-x86_64-linux-debian >> * libcxx-libcxxabi-x86_64-linux-debian-noexceptions >> *
Re: Zorg migration to GitHub/monorepo
Hello everyone, The staging master is ready to accept bots from the list I have sent yesterday. Don't wait too long. The master has been updated and works with both SVN and Github monorepo now. The following builders are already listening for changes in monorepo and building monorepo. More are coming. * clang-sphinx-docs * clang-tools-sphinx-docs * clang-x86_64-linux-abi-test * clang-lld-x86_64-2stage * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian * libcxx-sphinx-docs * libunwind-sphinx-docs * lld-sphinx-docs * lld-x86_64-darwin13 * lld-x86_64-ubuntu-fast * lldb-sphinx-docs * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast * llvm-clang-x86_64-win-fast <<-- ? * llvm-sphinx-docs * clang-x86_64-debian-fast * libcxx-libcxxabi-libunwind-x86_64-linux-debian * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian * libcxx-libcxxabi-x86_64-linux-debian * libcxx-libcxxabi-x86_64-linux-debian-noexceptions A friendly reminder. If your bots are using one of these build factories, you would need either update your build configurations to use one of the currently supported build factories, or port that factory to work with github and monorepo. * LLVMBuilder (3 bots) * PollyBuilder (3 bots) * LLDBBuilder (6 bots) * SanitizerBuilder (10 bots) * CUDATestsuiteBuilder (1 bot) - depends on ClangBuilder.getClangBuildFactory * AOSPBuilder (1 bot) - depends on PollyBuilder * AnnotatedBuilder (2 bots) * OpenMPBuilder (2 bots) * FuchsiaBuilder (1 bot) Thanks Galina On Fri, Oct 18, 2019 at 12:05 AM Galina Kistanova wrote: > Hello build bot owners! > > The staging master is ready. Please feel free to use it to make sure your > bots would work well with the monorepo and github. > > The following builders could be configured to build monorepo: > > * clang-atom-d525-fedora-rel > * clang-native-arm-lnt-perf > * clang-cmake-armv7-lnt > * clang-cmake-armv7-selfhost-neon > * clang-cmake-armv7-quick > * clang-cmake-armv7-global-isel > * clang-cmake-armv7-selfhost > * clang-cmake-aarch64-quick > * clang-cmake-aarch64-lld > * clang-cmake-aarch64-global-isel > * clang-ppc64be-linux-lnt > * clang-ppc64be-linux-multistage > * clang-ppc64le-linux-lnt > * clang-ppc64le-linux-multistage > * clang-ppc64be-linux > * clang-ppc64le-linux > * clang-s390x-linux > * clang-s390x-linux-multistage > * clang-s390x-linux-lnt > * clang-hexagon-elf > * clang-cmake-x86_64-avx2-linux > * clang-cmake-x86_64-avx2-linux-perf > * clang-cmake-x86_64-sde-avx512-linux > * clang-solaris11-amd64 > * clang-x64-ninja-win7 > * clang-solaris11-sparcv9 > * clang-cmake-armv7-full > * clang-cmake-thumbv7-full-sh > * clang-cmake-armv8-lld > * clang-cmake-aarch64-full > * clang-armv7-linux-build-cache > * clang-aarch64-linux-build-cache > * libcxx-libcxxabi-x86_64-linux-debian > * libcxx-libcxxabi-x86_64-linux-debian-noexceptions > * libcxx-libcxxabi-libunwind-x86_64-linux-debian > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 > * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 > * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 > * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17 > * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a > * libcxx-libcxxabi-x86_64-linux-ubuntu-32bit > * libcxx-libcxxabi-x86_64-linux-ubuntu-asan > * libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan > * libcxx-libcxxabi-x86_64-linux-ubuntu-msan > * libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu > * libcxx-libcxxabi-x86_64-linux-ubuntu-tsan > * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11 > * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std > * libcxx-libcxxabi-libunwind-armv7-linux > * libcxx-libcxxabi-libunwind-armv8-linux > * libcxx-libcxxabi-libunwind-armv7-linux-noexceptions > * libcxx-libcxxabi-libunwind-armv8-linux-noexceptions > * libcxx-libcxxabi-libunwind-aarch64-linux > * libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions > * ppc64le-lld-multistage-test > > These builders are already on the staging master. So, please ping me if > you would like to configure any of them to work with monorepo: > > * clang-freebsd11-amd64 > > These builders have been already tested and could be reconfigured without > staging as soon as public master is ready: > > * llvm-sphinx-docs > * clang-sphinx-docs > * clang-tools-sphinx-docs > * lld-sphinx-docs > * lldb-sphinx-docs > * libcxx-sphinx-docs > * libunwind-sphinx-docs > * clang-x86_64-debian-fast > * libcxx-libcxxabi-x86_64-linux-debian > * libcxx-libcxxabi-x86_64-linux-debian-noexceptions > * libcxx-libcxxabi-libunwind-x86_64-linux-debian > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > * lld-x86_64-darwin13 > * lld-x86_64-win7 > * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast > * llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast > * clang-x86_64-linux-abi-test > * clang-with-lto-ubuntu > * clang-with-thin-lto-ubuntu > * llvm-clang-x86_64-expensive-checks-win > * llvm-clang-x86_64-win-fast > * lld-x86_64-ubuntu-fast > * clang-lld-x86_64-2stage > * lld-perf-testsuite > > Thanks for your patience and help! >
Re: Zorg migration to GitHub/monorepo
On Mon, Oct 14, 2019 at 6:16 PM Galina Kistanova via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Hello everyone,
>
>
>
> We are in the middle of porting the majority of zorg to
> GitHub/monorepo. The following build factories will be ported and if you
> use one of those for your bots, you are all covered:
>
>
>
> * ClangBuilder.getClangCMakeBuildFactory (31 bots)
>
> * ClangBuilder.getClangCMakeGCSBuildFactory (2 bots)
>
> * LibcxxAndAbiBuilder (23 bots)
>
> * SphinxDocsBuilder (7 bots)
>
> * UnifiedTreeBuilder (11 bots)
>
> * ABITestsuitBuilder (1 bot) - based on UnifiedTreeBuilder
>
> * ClangLTOBuilder (2 bots) - based on UnifiedTreeBuilder
>
> * LLDPerformanceTesuiteBuilder (1 bot) - based on UnifiedTreeBuilder
>
>
>
> Some build factories will be deprecated. If you use one of these, please
> change your bot to use something else instead. Here is the list of
> deprecated build factories:
>
>
>
> * ClangBuilder.getClangBuildFactory (0 bots)
>
> * LLDBuilder (0 bots)
>
> * ClangAndLLDBuilder (0 bots)
>
>
>
> However, some special build factories and build factories with a few bots
> would need your attention.
>
> Here is the list of build factories in need of porting. Patches are
> welcome.
>
>
>
> * LLVMBuilder (3 bots)
>
> * PollyBuilder (3 bots)
>
> * LLDBBuilder (6 bots)
>
> * SanitizerBuilder (10 bots)
>
SanitizerBuilder already uses monorepo from github. Still it uses svn
BUILDBOT_REVISION. 'BUILDBOT_REVISION' is
WithProperties('%(revision:-None)s').
Not sure what is going to happen after migration.
> * CUDATestsuiteBuilder (1 bot) - depends on
> ClangBuilder.getClangBuildFactory
>
> * AOSPBuilder (1 bot) - depends on PollyBuilder
>
> * AnnotatedBuilder (2 bots)
>
> * OpenMPBuilder (2 bots)
>
> * FuchsiaBuilder (1 bot)
>
>
>
> Please feel free to ask if you have questions.
>
>
>
> Thanks
>
>
>
> Galina
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: Zorg migration to GitHub/monorepo
Hello build bot owners! The staging master is ready. Please feel free to use it to make sure your bots would work well with the monorepo and github. The following builders could be configured to build monorepo: * clang-atom-d525-fedora-rel * clang-native-arm-lnt-perf * clang-cmake-armv7-lnt * clang-cmake-armv7-selfhost-neon * clang-cmake-armv7-quick * clang-cmake-armv7-global-isel * clang-cmake-armv7-selfhost * clang-cmake-aarch64-quick * clang-cmake-aarch64-lld * clang-cmake-aarch64-global-isel * clang-ppc64be-linux-lnt * clang-ppc64be-linux-multistage * clang-ppc64le-linux-lnt * clang-ppc64le-linux-multistage * clang-ppc64be-linux * clang-ppc64le-linux * clang-s390x-linux * clang-s390x-linux-multistage * clang-s390x-linux-lnt * clang-hexagon-elf * clang-cmake-x86_64-avx2-linux * clang-cmake-x86_64-avx2-linux-perf * clang-cmake-x86_64-sde-avx512-linux * clang-solaris11-amd64 * clang-x64-ninja-win7 * clang-solaris11-sparcv9 * clang-cmake-armv7-full * clang-cmake-thumbv7-full-sh * clang-cmake-armv8-lld * clang-cmake-aarch64-full * clang-armv7-linux-build-cache * clang-aarch64-linux-build-cache * libcxx-libcxxabi-x86_64-linux-debian * libcxx-libcxxabi-x86_64-linux-debian-noexceptions * libcxx-libcxxabi-libunwind-x86_64-linux-debian * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17 * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a * libcxx-libcxxabi-x86_64-linux-ubuntu-32bit * libcxx-libcxxabi-x86_64-linux-ubuntu-asan * libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan * libcxx-libcxxabi-x86_64-linux-ubuntu-msan * libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu * libcxx-libcxxabi-x86_64-linux-ubuntu-tsan * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11 * libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std * libcxx-libcxxabi-libunwind-armv7-linux * libcxx-libcxxabi-libunwind-armv8-linux * libcxx-libcxxabi-libunwind-armv7-linux-noexceptions * libcxx-libcxxabi-libunwind-armv8-linux-noexceptions * libcxx-libcxxabi-libunwind-aarch64-linux * libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions * ppc64le-lld-multistage-test These builders are already on the staging master. So, please ping me if you would like to configure any of them to work with monorepo: * clang-freebsd11-amd64 These builders have been already tested and could be reconfigured without staging as soon as public master is ready: * llvm-sphinx-docs * clang-sphinx-docs * clang-tools-sphinx-docs * lld-sphinx-docs * lldb-sphinx-docs * libcxx-sphinx-docs * libunwind-sphinx-docs * clang-x86_64-debian-fast * libcxx-libcxxabi-x86_64-linux-debian * libcxx-libcxxabi-x86_64-linux-debian-noexceptions * libcxx-libcxxabi-libunwind-x86_64-linux-debian * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian * lld-x86_64-darwin13 * lld-x86_64-win7 * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast * llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast * clang-x86_64-linux-abi-test * clang-with-lto-ubuntu * clang-with-thin-lto-ubuntu * llvm-clang-x86_64-expensive-checks-win * llvm-clang-x86_64-win-fast * lld-x86_64-ubuntu-fast * clang-lld-x86_64-2stage * lld-perf-testsuite Thanks for your patience and help! Galina On Thu, Oct 17, 2019 at 5:04 PM Galina Kistanova wrote: > Hello everyone, > > The build bot is almost ready to move to github. > > As the next step we would migrate the staging master to listen for the > both changes, from SVN as it was before, and from github. > > Tonight I am going to update the staging (aka silent) master and it will > start working with github. > > I will send an email when it is done. > > If you bots use one of the ported build factories from the list in my > previous e-mail, please feel free to stage them for working with > monorepo/github and once you are happy, let me know, and I'll configure > them accordingly on the production master. Once that's done, you could move > the bots back to the production master and you are done. > > When you stage your bot, please follow these steps: > 1. Stop your bot between builds, if possible, > 2. Remove the bot working directory (usually this directory has a builder > name and is under directory where your bot is installed; if you are not > sure, check the 'builddir' param of your bot in > zorg/buildbot/osuosl/master/config/builders.py), > 3. Edit buildbot.tac in the directory where your bot is installed. Change > "port = 9990" line to "port = 9994". Save the change. > 4. Start your bot, make sure it connects to the staging master. > 5. Send me a mail with the staged bot names. > > Once you are happy with your bot building monorepo changes from github, > please send me an e-mail and I'll respond with the instructions of how to > get your bot back to production. > > Please be aware that staging master could restart often. Please let me > know if you are having long running builds. > > Feel free to ask if you have
Re: Zorg migration to GitHub/monorepo
Hello everyone, The build bot is almost ready to move to github. As the next step we would migrate the staging master to listen for the both changes, from SVN as it was before, and from github. Tonight I am going to update the staging (aka silent) master and it will start working with github. I will send an email when it is done. If you bots use one of the ported build factories from the list in my previous e-mail, please feel free to stage them for working with monorepo/github and once you are happy, let me know, and I'll configure them accordingly on the production master. Once that's done, you could move the bots back to the production master and you are done. When you stage your bot, please follow these steps: 1. Stop your bot between builds, if possible, 2. Remove the bot working directory (usually this directory has a builder name and is under directory where your bot is installed; if you are not sure, check the 'builddir' param of your bot in zorg/buildbot/osuosl/master/config/builders.py), 3. Edit buildbot.tac in the directory where your bot is installed. Change "port = 9990" line to "port = 9994". Save the change. 4. Start your bot, make sure it connects to the staging master. 5. Send me a mail with the staged bot names. Once you are happy with your bot building monorepo changes from github, please send me an e-mail and I'll respond with the instructions of how to get your bot back to production. Please be aware that staging master could restart often. Please let me know if you are having long running builds. Feel free to ask if you have questions. Please me know if you will see issues with the staging master. Thanks Galina On Mon, Oct 14, 2019 at 6:16 PM Galina Kistanova wrote: > Hello everyone, > > > > We are in the middle of porting the majority of zorg to > GitHub/monorepo. The following build factories will be ported and if you > use one of those for your bots, you are all covered: > > > > * ClangBuilder.getClangCMakeBuildFactory (31 bots) > > * ClangBuilder.getClangCMakeGCSBuildFactory (2 bots) > > * LibcxxAndAbiBuilder (23 bots) > > * SphinxDocsBuilder (7 bots) > > * UnifiedTreeBuilder (11 bots) > > * ABITestsuitBuilder (1 bot) - based on UnifiedTreeBuilder > > * ClangLTOBuilder (2 bots) - based on UnifiedTreeBuilder > > * LLDPerformanceTesuiteBuilder (1 bot) - based on UnifiedTreeBuilder > > > > Some build factories will be deprecated. If you use one of these, please > change your bot to use something else instead. Here is the list of > deprecated build factories: > > > > * ClangBuilder.getClangBuildFactory (0 bots) > > * LLDBuilder (0 bots) > > * ClangAndLLDBuilder (0 bots) > > > > However, some special build factories and build factories with a few bots > would need your attention. > > Here is the list of build factories in need of porting. Patches are > welcome. > > > > * LLVMBuilder (3 bots) > > * PollyBuilder (3 bots) > > * LLDBBuilder (6 bots) > > * SanitizerBuilder (10 bots) > > * CUDATestsuiteBuilder (1 bot) - depends on > ClangBuilder.getClangBuildFactory > > * AOSPBuilder (1 bot) - depends on PollyBuilder > > * AnnotatedBuilder (2 bots) > > * OpenMPBuilder (2 bots) > > * FuchsiaBuilder (1 bot) > > > > Please feel free to ask if you have questions. > > > > Thanks > > > > Galina > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Zorg migration to GitHub/monorepo
Hello everyone, We are in the middle of porting the majority of zorg to GitHub/monorepo. The following build factories will be ported and if you use one of those for your bots, you are all covered: * ClangBuilder.getClangCMakeBuildFactory (31 bots) * ClangBuilder.getClangCMakeGCSBuildFactory (2 bots) * LibcxxAndAbiBuilder (23 bots) * SphinxDocsBuilder (7 bots) * UnifiedTreeBuilder (11 bots) * ABITestsuitBuilder (1 bot) - based on UnifiedTreeBuilder * ClangLTOBuilder (2 bots) - based on UnifiedTreeBuilder * LLDPerformanceTesuiteBuilder (1 bot) - based on UnifiedTreeBuilder Some build factories will be deprecated. If you use one of these, please change your bot to use something else instead. Here is the list of deprecated build factories: * ClangBuilder.getClangBuildFactory (0 bots) * LLDBuilder (0 bots) * ClangAndLLDBuilder (0 bots) However, some special build factories and build factories with a few bots would need your attention. Here is the list of build factories in need of porting. Patches are welcome. * LLVMBuilder (3 bots) * PollyBuilder (3 bots) * LLDBBuilder (6 bots) * SanitizerBuilder (10 bots) * CUDATestsuiteBuilder (1 bot) - depends on ClangBuilder.getClangBuildFactory * AOSPBuilder (1 bot) - depends on PollyBuilder * AnnotatedBuilder (2 bots) * OpenMPBuilder (2 bots) * FuchsiaBuilder (1 bot) Please feel free to ask if you have questions. Thanks Galina ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
