[llvm-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
Russell Gallop via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 6 12:49:35 PST 2020
> Does ninja all run the tests too?
No, it just builds everything.
Russ
On Thu, 6 Feb 2020 at 16:43, Tom Stellard <tstellar at redhat.com> wrote:
> 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
> > bin/llvm-itanium-demangle-fuzzer
> > bin/llvm-microsoft-demangle-fuzzer
> > bin/llvm-PerfectShuffle
> > ...
> > lib/libclang.so
> > ...
> >
> > For completeness, should this do "ninja all", "ninja check-all" as most
> buildbot builders do?
> >
>
> Does ninja all run the tests too?
>
> -Tom
>
> > Thanks
> > Russ
> >
> > [1]
> https://github.com/llvm/actions/blob/master/build-test-llvm-project/main.js
>
> >
> > On Fri, 13 Dec 2019 at 22:07, John Byrd via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > > 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 and small companies to
> experiment with small changes in their own forks."
> >
> > Current usage limits for the free Github actions tier are:
> >
> > - You can execute up to 20 workflows concurrently per repository.
> > - You can execute up to 1000 API requests in an hour across all
> actions within a repository.
> > - Each job in a workflow can run for up to 6 hours of execution time.
> > - The number of jobs you can run concurrently across all
> repositories in your account depends on your GitHub plan.
> > - You can have a maximum concurrent set of 5 maximum concurrent
> MacOS jobs.
> >
> > So, this isn't enough juice to replace all the LLVM buildbots, but
> it is enough to have CI on *your personal fork* of LLVM. And having CI on
> everyone's personal fork, makes it that much more likely that your
> Phabricator patches will be correct the first time.
> >
> > Best of all, if you don't like Github's CI, you can completely
> ignore it and proceed with your current workflow.
> >
> > On Thu, Dec 12, 2019 at 10:53 AM Reid Kleckner <rnk at google.com
> <mailto:rnk at google.com>> wrote:
> >
> > I think everyone agrees that LLVM needs better CI, automatic
> pre-commit testing of various platforms, etc. This is not rocket science,
> it is standard practice for 2019 software engineering.
> >
> > 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?
> >
> > You may have seen that Christian Kuhnel has been working on a
> pre-commit testing bot that integrates with Phab:
> > https://reviews.llvm.org/p/merge_guards_bot/
> >
> https://github.com/google/llvm-premerge-checks/blob/master/docs/user_doc.md
> > I hope that ends up being the way forward and suits Tom's
> original release testing goals.
> >
> > On Wed, Dec 11, 2019 at 11:43 PM John Byrd via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > 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 proof of concept, is more
> important than we seem to be giving him credit for.
> >
> > As of this writing, the Github actions system permits all
> comers, six hours of CPU time per build platform. Due to this long CPU
> allotment, AFAIK, Github is one of the few CIs in town that lets anyone
> build and smoke llvm for free.
> >
> > Consider the workflow of someone who has never worked on
> llvm before. They will probably fork the monorepo on Github, in order to
> fix bugs or add a feature or such. At the moment they do this, they get a
> built-in workflow that will sanity-check their builds on several important
> targets. Zero braining involved.
> >
> > Giving Joe Programmer a CI system that magically smoke tests
> llvm, out of the box, after he forks the repo, is a compelling reason to
> make something like Tom's system a standard part of llvm master.
> >
> > Concerns might be raised that llvm is "preferring" one CI
> system over another. Some thoughts about that. First, because the
> monorepo's on Github, you'll end up going to github.com <http://github.com>
> anyway to get your first pull. Second, nothing about Github actions
> precludes supporting other CI systems in the future.
> >
> > Thanks for your kind consideration.
> >
> > --
> > ---
> >
> > John Byrd
> > Gigantic Software
> > 2321 E 4th Street
> > Suite C #429
> > Santa Ana, CA 92705-3862
> > http://www.giganticsoftware.com
> > T: (949) 892-3526 <tel:%28949%29%20892-3526> F: (206)
> 309-0850 <tel:%28206%29%20309-0850>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> >
> > --
> > ---
> >
> > John Byrd
> > Gigantic Software
> > 2321 E 4th Street
> > Suite C #429
> > Santa Ana, CA 92705-3862
> > http://www.giganticsoftware.com
> > T: (949) 892-3526 F: (206) 309-0850
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200206/ff7d94b9/attachment.html>
More information about the llvm-dev
mailing list