gdb-bof-cauldron-2019/gdb-bof-cauldron-2019.tex

165 lines
3.8 KiB
TeX

% 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}