/usr/share/doc/git-buildpackage/manual-html/gbp.building.hooks.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Invoking external programs: Building Debian Packages with git-buildpackage</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.79.1">
<link rel="home" href="index.html" title="Building Debian Packages with git-buildpackage">
<link rel="up" href="gbp.building.html" title="Building Packages from the Git™ Repository">
<link rel="prev" href="gbp.building.html" title="Building Packages from the Git™ Repository">
<link rel="next" href="gbp.patches.html" title="Working with Patches">
<link rel="stylesheet" href="style.css" type="text/css">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="5"><tr valign="middle">
<td width="100%" align="left" class="shortcuts"></td>
<td><a accesskey="h" href="index.html"><img src="home.png" width="16" height="16" border="0" alt="Home"></a></td>
<td><a accesskey="u" href="gbp.building.html"><img src="up.png" width="16" height="16" border="0" alt="Up"></a></td>
<td><a accesskey="p" href="gbp.building.html"><img src="left.png" width="16" height="16" border="0" alt="Prev"></a></td>
<td><a accesskey="n" href="gbp.patches.html"><img src="right.png" width="16" height="16" border="0" alt="Next"></a></td>
</tr></table>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="gbp.building.hooks"></a>Invoking external programs</h2></div></div></div>
<p>
    Besides the commands for cleaning the package build dir
    (<code class="option">cleaner</code>) and building the package
    (<code class="option">builder</code>), you can also invoke hooks during the package
    build: immediately before a build (<code class="option">prebuild</code>),
    after a successful build (<code class="option">postbuild</code>), and after
    creating a tag (<code class="option">posttag</code>). Typical applications are running
    <span class="productname">lintian</span>™ or pushing changes into a remote
    repository.
    </p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="gbp.building.lintian"></a>Running lintian</h3></div></div></div>
<p><span class="command"><strong>gbp buildpackage</strong></span> exports several variables into the
	<code class="option">posttag</code>'s environment (for details see the <a class="xref" href="man.gbp.buildpackage.html" title="gbp-buildpackage"><span class="refentrytitle">gbp-buildpackage</span>(1)</a> manual page).
	To invoke <span class="productname">lintian</span>™, we need to tell it where to find the changes file:
</p>
<pre class="programlisting">
<span class="command"><strong>gbp buildpackage</strong></span> <code class="option">--git-postbuild</code>=<em class="replaceable"><code>'lintian $GBP_CHANGES_FILE'</code></em>
</pre>
<p>
        To call <span class="productname">lintian</span>™ automatically after each successful build, add:
</p>
<pre class="programlisting">
<code class="option">postbuild</code>=<em class="replaceable"><code>lintian $GBP_CHANGES_FILE</code></em>
</pre>
<p>
	to your <code class="filename">.gbp.conf</code>.
    </p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="gbp.building.push"></a>Pushing into a remote repository</h3></div></div></div>
<p>If you want to push your changes automatically after a successful build and tag,
	you can use <span class="command"><strong>gbp buildpackage</strong></span>'s posttag hook. A very simple invocation would look like this:
</p>
<pre class="programlisting">
<span class="command"><strong>gbp buildpackage</strong></span> <code class="option">--git-tag</code> <code class="option">--git-posttag</code>=<em class="replaceable"><code>"git push &amp;&amp; git push --tags"</code></em>
</pre>
<p>
	This assumes you have set up a remote repository to push to in
        <code class="filename">.git/config</code>.</p>
<p>Usually, you want to make sure you don't push out any
        unrelated changes into the remote repository. This is handled by the
        following hook which only pushes out the created tag to where you pulled
        from and also forwards the corresponding remote branch to that position:
</p>
<pre class="programlisting">
#!/bin/sh -e
#
# gbp-posttag-push: post tag hook to push out the newly created tag and to
# forward the remote branch to that position

if ! REMOTE=$(git config --get branch."${GBP_BRANCH}".remote); then
    REMOTE=origin
fi

if [ "$GBP_TAG" ]; then
     echo "Pushing $GBP_TAG to $REMOTE"
     git push "$REMOTE" "$GBP_TAG"
else
     echo "GBP_TAG not set."
     exit 1
fi

if [ "$GBP_SHA1" ] &amp;&amp; [ "$GBP_BRANCH" ]; then
    git push "$REMOTE" "$GBP_SHA1":"$GBP_BRANCH"
else
    echo "GBP_SHA1 or GBP_BRANCH not set."
    exit 1
fi
echo "done."
</pre>
<p>
	<code class="envar">GBP_TAG</code>, <code class="envar">GBP_SHA1</code>
        and <code class="envar">GBP_BRANCH</code> are passed to the hook via the
        environment. To call this hook automatically upon tag creation, add:
</p>
<pre class="programlisting">
<code class="option">posttag</code>=<em class="replaceable"><code>"gbp-posttag-push"</code></em>
</pre>
<p>
	to your <code class="filename">.gbp.conf</code> and make sure <code class="filename">gbp-push</code>
	is somewhere in your <code class="envar">$PATH</code>. On <span class="productname">Debian</span>™
	systems, a more complete example can be found in
	<code class="filename">/usr/share/doc/examples/git-buildpackage/examples/gbp-posttag-push</code>.
    </p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="gbp.building.postexport"></a>Running postexport hook</h3></div></div></div>
<p><span class="command"><strong>gbp buildpackage</strong></span> exports several variables into the
	<code class="option">postexport</code>'s environment (for details see
	the <a class="xref" href="man.gbp.buildpackage.html" title="gbp-buildpackage"><span class="refentrytitle">gbp-buildpackage</span>(1)</a> manual page). The motivation
	for the postexport action is to allow further adjustment of
	the sources prior to building the package. A typical use case
	scenario is to allow creating multiple source and binary
	packages from one <span class="productname">Debian</span>™ branch, e.g. the bootstrap gcc and
	in the next stage the full gcc.
    </p>
<p>The postexport action postpones the creation of the
      upstream tarball, so that the metadata for creating it is
      already present in the exported source tree. The example
      postexport script below (<code class="filename">crosstoolchain-expand.sh</code>)
      expands changelog, lintian override files, rules and control files
      according to an environment variable <code class="envar">PKG_FLAVOR</code>.
    </p>
<p>Sample <code class="filename">gbp.conf</code> - enables source tree export
    by specifying the export directory:
    </p>
<pre class="programlisting">
[buildpackage]
# use a build area relative to the git repository
export-dir = ../build-area
# disable the since the sources are being exported first
cleaner =
# post export script that handles expansion of <span class="productname">Debian</span>™ specific files
postexport = crosstoolchain-expand.sh
</pre>
<p>Sample postexport script: <code class="filename">crosstoolchain-expand.sh</code></p>
<pre class="programlisting">
#!/bin/sh
#
# Purpose: this script is intended for creating multiple source and
# binary Debian packages from one source tree. It can be used in
# conjunction with git-buildpackage that support a postexport hook
#
# A typical use is preparing a bootstrap gcc package that is needed
# for building newlib and then preparing a full gcc package from the
# same source tree. The user may specify the package flavor via
# PKG_FLAVOR environmental variable. 
#
#
# The script expands/processes the following files:
#
# - changelog.tmpl is converted to standard Debian changelog
#
#
# - all binary package lintian override template files are expanded
#   and renamed to the requested package flavor
#
# - source package lintian override template file is expanded and
#   renamed
#
# - rules.$PKG_FLAVOR and control.$PKG_FLAVOR are renamed to rules and
#   control resp.


# the template string has been carefully chosen, so that
# e.g. changelogs that refer to the source package can still be
# processed by dch/git-dch resp.
TMPL_STR=-XXXXXX

# by default replace string for the template is empty
REPLACE_STR=

if [ -n "$PKG_FLAVOR" ]; then
    REPLACE_STR=-$PKG_FLAVOR
fi

REPLACE_EXPR="s/$TMPL_STR/$REPLACE_STR/g"


# actual processing of relevant files
cd debian

# expand the template changelog
# remove the symlinked version
rm changelog
chglog_tmpl=changelog.tmpl
[ -f "$chglog_tmpl" ] || {
    echo "Missing changelog template (debian/$chglog_tmpl)"
    exit 1
}
cat changelog.tmpl | sed -e "$REPLACE_EXPR" &gt; changelog
rm changelog.tmpl

# process binary package lintian overrides - each override must match
# its package name
for f in *.lintian-overrides.tmpl; do
    outfile=${f%.tmpl}
    [ -f "$f" ] || {
	echo "Missing lintian override files for binary packages"
	exit 1
    }
    cat $f | sed -e "$REPLACE_EXPR" &gt; ${outfile/$TMPL_STR/$REPLACE_STR}
    rm $f
done

# process the only source package lintian override
source_lintian=source/lintian-overrides.tmpl
cat $source_lintian | sed -e "$REPLACE_EXPR" &gt; ${source_lintian%.tmpl}
rm $source_lintian

# rules and control file are package flavor specific
[ -f rules.$PKG_FLAVOR ] &amp;&amp; mv rules.$PKG_FLAVOR rules
[ -f control.$PKG_FLAVOR ] &amp;&amp; mv control.$PKG_FLAVOR control
rm -f rules.* control.*

exit 0
</pre>
</div>
</div>
<div class="footer">
<hr>Generated by GTK-Doc</div>
</body>
</html>
git-buildpackage 0.9.8 / usr / share / doc / git-buildpackage / manual-html / gbp.building.hooks.html
