asterisk/tests/CI/installAsterisk.sh

44 lines
1.2 KiB
Bash
Raw Normal View History

#!/usr/bin/env bash
CIDIR=$(dirname $(readlink -fn $0))
UNINSTALL=0
UNINSTALL_ALL=0
source $CIDIR/ci.functions
MAKE=`which make`
if [ x"$DESTDIR" != x ] ; then
mkdir -p "$DESTDIR"
fi
build: Refactor the earlier "basebranch" commit Recap from earlier commit: If you have a development branch for a major project that will receive gerrit reviews it'll probably be named something like "development/16/newproject" or a work branch based on that "development" branch. That will necessitate setting "defaultbranch=development/16/newproject" in .gitreview. The make_version script uses that variable to construct the asterisk version however, which results in versions like "GIT-development/16/newproject-ee582a8c7b" which is probably not what you want. It also constructs the URLs for downloading external modules with that version, which will fail. Fast-forward: The earlier attempt at adding a "basebranch" variable to .gitreview didn't work out too well in practice because changes were made to .gitreview, which is a checked-in file. So, if you wanted to rebase your work branch on the base branch, rebase would attempt to overwrite your .gitreview with the one from the base branch and complain about a conflict. This is a slighltly different approach that adds three methods to determine the mainline branch: 1. --- MAINLINE_BRANCH from the environment If MAINLINE_BRANCH is already set in the environment, that will be used. This is primarily for the Jenkins jobs. 2. --- .develvars Instead of storing the basebranch in .gitreview, it can now be stored in a non-checked-in ".develvars" file and keyed by the current branch. So, if you were working on a branch named "new-feature-work" based on "development/16/new-feature" and wanted to push to that branch in Gerrit but wanted to pull the external modules for 16, you'd create the following .develvars file: [branch "new-feature-work"] mainline-branch = 16 The .gitreview file would still look like: [gerrit] defaultbranch=development/16/new-feature ...which would cause any reviews pushed from "new-feature-work" to go to the "development/16/new-feature" branch in Gerrit. The key is that the .develvars file is NEVER checked in (it's been added to .gitignore). 3. --- Well Known Development Branch If you're actually working in a branch named like "development/<mainline_branch>/some-feature", the mainline branch will be parsed from it. 4. --- .gitreview If none of the earlier conditions exist, the .gitreview "defaultbranch" variable will be used just as before. Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
2022-02-17 16:26:46 +00:00
if [[ "$BRANCH_NAME" =~ devel(opment)?/([0-9]+)/.+ ]] ; then
export MAINLINE_BRANCH="${BASH_REMATCH[2]}"
fi
_version=$(./build_tools/make_version .)
destdir=${DESTDIR:+DESTDIR=$DESTDIR}
build: Refactor the earlier "basebranch" commit Recap from earlier commit: If you have a development branch for a major project that will receive gerrit reviews it'll probably be named something like "development/16/newproject" or a work branch based on that "development" branch. That will necessitate setting "defaultbranch=development/16/newproject" in .gitreview. The make_version script uses that variable to construct the asterisk version however, which results in versions like "GIT-development/16/newproject-ee582a8c7b" which is probably not what you want. It also constructs the URLs for downloading external modules with that version, which will fail. Fast-forward: The earlier attempt at adding a "basebranch" variable to .gitreview didn't work out too well in practice because changes were made to .gitreview, which is a checked-in file. So, if you wanted to rebase your work branch on the base branch, rebase would attempt to overwrite your .gitreview with the one from the base branch and complain about a conflict. This is a slighltly different approach that adds three methods to determine the mainline branch: 1. --- MAINLINE_BRANCH from the environment If MAINLINE_BRANCH is already set in the environment, that will be used. This is primarily for the Jenkins jobs. 2. --- .develvars Instead of storing the basebranch in .gitreview, it can now be stored in a non-checked-in ".develvars" file and keyed by the current branch. So, if you were working on a branch named "new-feature-work" based on "development/16/new-feature" and wanted to push to that branch in Gerrit but wanted to pull the external modules for 16, you'd create the following .develvars file: [branch "new-feature-work"] mainline-branch = 16 The .gitreview file would still look like: [gerrit] defaultbranch=development/16/new-feature ...which would cause any reviews pushed from "new-feature-work" to go to the "development/16/new-feature" branch in Gerrit. The key is that the .develvars file is NEVER checked in (it's been added to .gitignore). 3. --- Well Known Development Branch If you're actually working in a branch named like "development/<mainline_branch>/some-feature", the mainline branch will be parsed from it. 4. --- .gitreview If none of the earlier conditions exist, the .gitreview "defaultbranch" variable will be used just as before. Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
2022-02-17 16:26:46 +00:00
declare -p _version
declare -p destdir
[ $UNINSTALL -gt 0 ] && ${MAKE} ${destdir} uninstall
[ $UNINSTALL_ALL -gt 0 ] && ${MAKE} ${destdir} uninstall-all
${MAKE} ${destdir} install || ${MAKE} ${destdir} NOISY_BUILD=yes install || exit 1
${MAKE} ${destdir} samples install-headers
if [ x"$DESTDIR" != x ] ; then
sed -i -r -e "s@\[directories\]\(!\)@[directories]@g" $DESTDIR/etc/asterisk/asterisk.conf
sed -i -r -e "s@ /(var|etc|usr)/@ $DESTDIR/\1/@g" $DESTDIR/etc/asterisk/asterisk.conf
fi
set +e
if [ x"$USER_GROUP" != x ] ; then
chown -R $USER_GROUP $DESTDIR/var/cache/asterisk
chown -R $USER_GROUP $DESTDIR/var/lib/asterisk
chown -R $USER_GROUP $DESTDIR/var/spool/asterisk
chown -R $USER_GROUP $DESTDIR/var/log/asterisk
chown -R $USER_GROUP $DESTDIR/var/run/asterisk
chown -R $USER_GROUP $DESTDIR/etc/asterisk
fi
ldconfig