similar to: premerge-testing down

Hi Christian, I’m sorry, but this is still on my todo list. I’ve been a bit DoS’d lately, but I do hope to come back to this soon. -Chris > On Feb 21, 2020, at 4:24 AM, Christian Kühnel <kuhnel at google.com> wrote: > > Hi Chris, > > Did you reach any decision on how to move forward? > I would be happy if we get this (or something similar) started... > >

Hi Galina, How can I set a builder to "batch mode"? I could not find any documentation or examples for that... Best, Christian On Mon, Aug 3, 2020 at 9:33 AM Christian Kühnel <kuhnel at google.com> wrote: > Hi folks, > > happy to set it to batch mode, if someone tells me where to configure it :) > > Otherwise we could also upgrade the machine from 16 to 32

On Wed, Jan 22, 2020 at 11:24 PM David Greene <greened at obbligato.org> wrote: > Christian Kühnel via llvm-dev <llvm-dev at lists.llvm.org> writes: > > >>> In Github pull 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

Please forgive the incorrect threading on this reply to Tom Stellard's RFC. > I would like to start using GitHub Actions[1] for CI testing on the release/* > branches. As far as I know we don't have any buildbots listening to the > release branches, and I think GitHub Actions are a good way for us to > quickly bring-up some CI jobs there. Personally, I feel that Tom's

Hi folks, Another thought on the topic is tooling support and tool integration: There is a hughe ecosystem around Github and very little around Phabricator. It took me 2 days to set up build jobs for the 10.x release branch [1]. There are nice build integrations for Github and it was smooth sailing. Setting up a build job for pull requests would just be a few clicks now. In contrast I've

On Wed, Mar 4, 2020 at 9:42 AM Louis Dionne <ldionne at apple.com> wrote: > > > On Mar 4, 2020, at 12:13, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > >> Mehdi, Chris & others, >> >> I guess I did not express the main reasons for wanting to switch over

On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > Mehdi, Chris & others, > > I guess I did not express the main reasons for wanting to switch over very > well in my original message. > You original message was about “ commit attribution”, but now it is all about testing? Instead of jumping to a solution (pull-request) why not expressing the

> I think my concern is that LLVM could prove to be too big and require too many resources for github's infrastructure. How many patches go into LLVM a day, and how many build and test jobs does GitHub allow users to run concurrently before being throttled? Please, no one confuse "what should be LLVM's official CIs" with "what can we do to make it easier for individuals

On 02/06/2020 08:41 AM, Russell Gallop wrote: > Hi Tom, > > Thank you for setting this up. It's very useful. > > One question about what this builds. It only builds "ninja check-all", not "ninja all"[1]. check-all isn't a strict superset of all so while this covers most things, this does miss building a few things such as: > bin/clang-offload-wrapper

Thanks for the reply. Typing in my username and clicking "Forgot password?" got me a link I could use to log in. It'd still be good if federated login worked again. Is there an upstream issue for this? On Thu, Nov 28, 2019 at 5:09 PM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Yes this was broken for me too, there was another post on here about this

Hi all, Thank you for everyone that participated in the first round of the discussion <http://lists.llvm.org/pipermail/llvm-dev/2020-January/138267.html>. I’ve incorporated feedback into the draft of the proposal, and I’d appreciate it if you could take another look and share your thoughts. One piece of feedback is that GitHub gists aren’t great for detailed feedback and iteration, so I

Hi everyone, In the reviewing system, after a patch is approved, what should be the following step? I assume I'll have to make sure the patch hasn't broken anything, before pushing it, so I'll wan't to run a full build+tests, probably in a remote sterile environment (like a jenkins server). Do we have an integration system like this? Or should I just trust the build+tests on my

+1 for batching. In practice it's probably more important that things get run for every MLIR checkin, and not necessarily for every LLVM checkin. Steve On Fri, Jul 31, 2020 at 9:26 AM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Indeed there is quite a backlog here right now: > http://lab.llvm.org:8011/builders/mlir-windows and here >

On 2020-03-04, Louis Dionne via llvm-dev wrote: > > >> On Mar 4, 2020, at 12:13, Mehdi AMINI <joker.eph at gmail.com> wrote: >> >> >> >> On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com <mailto:ldionne at apple.com>> wrote: >> Mehdi, Chris & others, >> >> I guess I did not express the main reasons for

On Tue, Feb 25, 2020 at 4:19 AM Christian Kühnel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Louis, > > I think this is a good idea. We should start with some local experiments > where people are willing to try it and figure out how well that works and > what does not. Why not allow this for "not significant" changes? They are > merged without review

First, I love this bot:) It makes LLVM's "pushing to master" practise less awful:) Now the main topic... > clang-tidy: fail. Please fix clang-tidy findings. For example, on https://reviews.llvm.org/D72103#1801916 , merge_guards_bot reports clang-tidy findings of existing code, not just the modified code. I think https://github.com/google/llvm-premerge-checks should use

> > In Github pull 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. >> > > How would that be true? Given that upstream keep changing during the > period of review? The commit is going to have to be rebased

(Copying from Discourse) All A couple of months ago I added the following page documentation Clang-Formatted-Status <http://clang.llvm.org/docs/ClangFormattedStatus.html> to track the status of “How Much” clang-formatted the LLVM/Clang project is. I’m a contributor to clang-format and would like to see LLVM 100% clang formatted so we can use LLVM as a massive test-suite for clang-format

I worte in my last mail that when I ue compiz git fullscreen videos are no longer ontop of the gnome-panel... that means that the gnome-panel is still visible while playing the video in fullscreen. The commit which I said may caused it has nothing to do with it compiz does not build if I revert it). again with older compiz and metacity it works fine. (now I am running 20070316). Anyone else wiith

Hello Community Congratulations everyone for the reunification. To kick off the process, shall we finalize channels we are going to use for communication so that all the developers involved know what is going on and where. Which ML and IRC would be used for 'semi-official' communication etc. 1. Danny, Quinn and Marex have already started working on compiz-plugins-beryl-premerge tree on