search for: buildkit

Hello friends, We are switching the pre-merge test build system from Jenkins to Buildkite. That will give authors and reviewers more transparency on what's going on during the build process. For now only members of "pre-merge beta testing" [0] group are affected. As usual, please tell us if something is off. [0] https://reviews.llvm.org/project/view/78/ Kind regards, M...

...thank in advance > > MyDeveloperDay. > > > > > On Wed, Jun 3, 2020 at 1:40 PM Mikhail Goncharov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello friends, >> >> We are switching the pre-merge test build system from Jenkins to >> Buildkite. >> That will give authors and reviewers more transparency on what's going on >> during the build process. For now only members of "pre-merge beta testing" >> [0] group are affected. >> >> As usual, please tell us if something is off. >> >> [...

...ull requests there is always a git commit that you can just feed to the build server. And you can be sure of what really gets merged. You review, build and test exactly the change that gets merged afterwards. So from the build server perspective, Github is clearly the better solution. [1] https://buildkite.com/llvm-project/llvm-release-builds [2] https://github.com/google/llvm-premerge-checks/blob/master/docs/user_doc.md Best, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/8dbda8dd/attachment...

...or of migrating from Phab to GH for the full-project). >>> >>> Oh I'm happy to add Github support as soon as someone switches on PRs. This is soooooo much easier to set up and maintain than the Phabricator integration. And we already have builds for the release branch (https://buildkite.com/llvm-project/llvm-release-builds <https://buildkite.com/llvm-project/llvm-release-builds>) anyway. So we could easily scale that up. And we can only get pre-merge testing on Phabricator to a certain point, as it's not triggering builds for ~50% of the code reviews. >>> >&...

...om Phab to GH for the >> full-project). >> > > Oh I'm happy to add Github support as soon as someone switches on PRs. > This is soooooo much easier to set up and maintain than the Phabricator > integration. And we already have builds for the release branch ( > https://buildkite.com/llvm-project/llvm-release-builds) anyway. So we > could easily scale that up. And we can only get pre-merge testing on > Phabricator to a certain point, as it's not triggering builds for ~50% of > the code reviews. > > @Chris Lattner > >> Although I am one of the (m...

Renato Golin <rengolin at gmail.com> writes: > On Thu, 17 Oct 2019 at 18:10, David Greene <greened at obbligato.org> wrote: >> From other discussion, it sounds like at least some people are open to >> asm tests under clang. I think that should be fine. But there are >> probably other kinds of end-to-end tests that should not live under >> clang. > >

...t;> full-project). >>> >> >> Oh I'm happy to add Github support as soon as someone switches on PRs. >> This is soooooo much easier to set up and maintain than the Phabricator >> integration. And we already have builds for the release branch ( >> https://buildkite.com/llvm-project/llvm-release-builds) anyway. So we >> could easily scale that up. And we can only get pre-merge testing on >> Phabricator to a certain point, as it's not triggering builds for ~50% of >> the code reviews. >> >> @Chris Lattner >> >>>...

...t;>>> >>> >>> Oh I'm happy to add Github support as soon as someone switches on PRs. >>> This is soooooo much easier to set up and maintain than the Phabricator >>> integration. And we already have builds for the release branch ( >>> https://buildkite.com/llvm-project/llvm-release-builds) anyway. So we >>> could easily scale that up. And we can only get pre-merge testing on >>> Phabricator to a certain point, as it's not triggering builds for ~50% of >>> the code reviews. >>> >>> @Chris Lattner &...

Hi, I know there has been significant discussion about "moving" from Phabricator to GitHub reviews and pull requests, etc. I'm not suggesting that we do anything in terms of global LLVM policy. However, as a maintainer of libc++, I commit __a lot__ of other people's code for them. It would be a huge time saver for me if I could nicely suggest to contributors (not force them) to