commit 4489b7e7b2a4313557f0d783d7c8286b61516abf Author: Sergio Durigan Junior Date: Fri Sep 13 20:58:46 2019 -0400 First commit diff --git a/gdb-bof-cauldron-2019.org b/gdb-bof-cauldron-2019.org new file mode 100644 index 0000000..1fa34b0 --- /dev/null +++ b/gdb-bof-cauldron-2019.org @@ -0,0 +1,100 @@ +#+OPTIONS: toc:nil date:nil +#+CREATOR: Emacs 26.1 (Org mode 9.1.9) +#+TITLE: GDB tests, CI & Buildbot BoF +#+AUTHOR: Sergio Durigan Junior @@latex:\\@@ sergiodj@redhat.com +#+LANGUAGE: en + +* License + +- License: *Creative Commons Attribution 4.0 International License (CC-BY-4.0)* + +- https://creativecommons.org/licenses/by/4.0/ + +* How was it? + +- GDB Buildbot started in 2015 as a personal project. + +#+BEAMER: \pause + +- We just had *2* machines serving *4* Fedora =x86_64= workers at the + time. And no /try builds/! + +#+BEAMER: \pause + +- Initially it stored the test results in a git repository. This + proved too inefficient over time... + +* And now? + +- The master runs in a dedicated VM at *OSCI* (@@latex:\textbf{O}@@pen + @@latex:\textbf{S}@@ource @@latex:\textbf{C}@@ommunity + @@latex:\textbf{I}@@nfrastructure). + +#+BEAMER: \pause + +- Most of our builders support /try builds/! + +#+BEAMER: \pause + +- *14* workers (*11* machines): + + #+BEAMER: \pause + + - Sergio (Red Hat): *2* machines (Fedora =x86_64=) + + - Alan Hayward (ARM): *2* machines (Ubuntu =ARM 32= and =64=) + + - Rainer Orth (CeBiTec.Uni-Bielefeld.DE): *2* machines (Solaris + =amd64= and =sparcv9=) + + - David Edelsohn: *3* machines (RHEL 7.1 =s390x=, AIX =POWER8= and + Debian Jessie =s390x=) + + - Edjunior Machado: *1* machine (CentOS 7 =PPC64LE=) + + - Mark Wielaard: *1* machine (Fedora =s390x=) + +#+BEAMER: \pause + +- Test results are stored directly on-disk, and “garbage-collected” + every week (tests older than 4 months are deleted). + +* How does it work? + +- + +* Notifications + +- To /gdb-testers/: whenever we detect a possible regression in an + upstream commit. + +#+BEAMER: \pause + +- To the /author/: on /try builds/, or when his/her commit broke GDB. + +#+BEAMER: \pause + +- To /gdb-patches/: when a commit breaks GDB. + +#+BEAMER: \pause + +- Breakage notifications are usually reliable. Regression + notifications are not (just look at /gdb-testers/). + +* Problems and challenges + +- Racy testcases. Perhaps the most difficult/persistent problem? + +#+BEAMER: \pause + +- Lots of test messages are non-unique. This makes it really hard to + compare test results and find regressions. + +#+BEAMER: \pause + +- Better way to store and retrieve test results (current way is + “enough” for what we need, but it can certainly be improved). + +#+BEAMER: \pause + +- diff --git a/gdb-bof-cauldron-2019.pdf b/gdb-bof-cauldron-2019.pdf new file mode 100644 index 0000000..37a4d39 Binary files /dev/null and b/gdb-bof-cauldron-2019.pdf differ diff --git a/gdb-bof-cauldron-2019.tex b/gdb-bof-cauldron-2019.tex new file mode 100644 index 0000000..b5ca514 --- /dev/null +++ b/gdb-bof-cauldron-2019.tex @@ -0,0 +1,164 @@ +% Created 2019-09-12 Thu 13:03 +% Intended LaTeX compiler: pdflatex +\documentclass[presentation]{beamer} +\usepackage[utf8]{inputenc} +\usepackage[T1]{fontenc} +\usepackage{graphicx} +\usepackage{grffile} +\usepackage{longtable} +\usepackage{wrapfig} +\usepackage{rotating} +\usepackage[normalem]{ulem} +\usepackage{amsmath} +\usepackage{textcomp} +\usepackage{amssymb} +\usepackage{capt-of} +\usepackage{hyperref} +\usepackage{color} +\usepackage{listings} +\usetheme{default} +\author{Sergio Durigan Junior \\ sergiodj@redhat.com} +\date{} +\title{GDB tests, CI \& Buildbot BoF} +\hypersetup{ + pdfauthor={Sergio Durigan Junior \\ sergiodj@redhat.com}, + pdftitle={GDB tests, CI \& Buildbot BoF}, + pdfkeywords={}, + pdfsubject={}, + pdfcreator={Emacs 26.1 (Org mode 9.1.9)}, + pdflang={English}} +\begin{document} + +\maketitle + +\begin{frame}[label={sec:orgbad1c50}]{License} +\begin{itemize} +\item License: \alert{Creative Commons Attribution 4.0 International License (CC-BY-4.0)} + +\item \url{https://creativecommons.org/licenses/by/4.0/} +\end{itemize} +\end{frame} + +\begin{frame}[fragile,label={sec:org4538604}]{How was it?} + \begin{itemize} +\item GDB Buildbot started in 2015 as a personal project. +\end{itemize} + +\pause + +\begin{itemize} +\item We just had \alert{2} machines serving \alert{4} Fedora \texttt{x86\_64} workers at the +time. And no \emph{try builds}! +\end{itemize} + +\pause + +\begin{itemize} +\item Initially it stored the test results in a git repository. This +proved too inefficient over time\ldots{} +\end{itemize} +\end{frame} + +\begin{frame}[fragile,label={sec:org9dadf47}]{And now?} + \begin{itemize} +\item The master runs in a dedicated VM at \alert{OSCI} (\textbf{O}pen +\textbf{S}ource \textbf{C}ommunity +\textbf{I}nfrastructure). +\end{itemize} + +\pause + +\begin{itemize} +\item Most of our builders support \emph{try builds}! +\end{itemize} + +\pause + +\begin{itemize} +\item \alert{14} workers (\alert{11} machines): + +\pause + +\begin{itemize} +\item Sergio (Red Hat): \alert{2} machines (Fedora \texttt{x86\_64}) + +\item Alan Hayward (ARM): \alert{2} machines (Ubuntu \texttt{ARM 32} and \texttt{64}) + +\item Rainer Orth (CeBiTec.Uni-Bielefeld.DE): \alert{2} machines (Solaris +\texttt{amd64} and \texttt{sparcv9}) + +\item David Edelsohn: \alert{3} machines (RHEL 7.1 \texttt{s390x}, AIX \texttt{POWER8} and +Debian Jessie \texttt{s390x}) + +\item Edjunior Machado: \alert{1} machine (CentOS 7 \texttt{PPC64LE}) + +\item Mark Wielaard: \alert{1} machine (Fedora \texttt{s390x}) +\end{itemize} +\end{itemize} + +\pause + +\begin{itemize} +\item Test results are stored directly on-disk, and “garbage-collected” +every week (tests older than 4 months are deleted). +\end{itemize} +\end{frame} + +\begin{frame}[label={sec:orgd76b986}]{How does it work?} +\begin{itemize} +\item +\end{itemize} +\end{frame} + +\begin{frame}[label={sec:orge36c4d4}]{Notifications} +\begin{itemize} +\item To \emph{gdb-testers}: whenever we detect a possible regression in an +upstream commit. +\end{itemize} + +\pause + +\begin{itemize} +\item To the \emph{author}: on \emph{try builds}, or when his/her commit broke GDB. +\end{itemize} + +\pause + +\begin{itemize} +\item To \emph{gdb-patches}: when a commit breaks GDB. +\end{itemize} + +\pause + +\begin{itemize} +\item Breakage notifications are usually reliable. Regression +notifications are not (just look at \emph{gdb-testers}). +\end{itemize} +\end{frame} + +\begin{frame}[label={sec:orgcf5098b}]{Problems and challenges} +\begin{itemize} +\item Racy testcases. Perhaps the most difficult/persistent problem? +\end{itemize} + +\pause + +\begin{itemize} +\item Lots of test messages are non-unique. This makes it really hard to +compare test results and find regressions. +\end{itemize} + +\pause + +\begin{itemize} +\item Better way to store and retrieve test results (current way is +“enough” for what we need, but it can certainly be improved). +\end{itemize} + +\pause + +\begin{itemize} +\item +\end{itemize} +\end{frame} +\end{document} diff --git a/submit-patch.dot b/submit-patch.dot new file mode 100644 index 0000000..178104d --- /dev/null +++ b/submit-patch.dot @@ -0,0 +1,10 @@ +digraph submitpatch { + graph [ dpi = 300 ]; + "Patch" -> "Buildbot" [label=" Submit"]; + "Buildbot" -> "Scheduler"; + "Scheduler" -> "Builder 1"; + "Scheduler" -> "Builder 2"; + "Scheduler" -> "Builder 3"; + "Scheduler" -> "..."; + "Scheduler" -> "Builder N"; +}