Files
asterisk/build_tools/make_version

214 lines
6.0 KiB
Plaintext
Raw Normal View History

#!/bin/sh
AWK=${AWK:-awk}
GIT=${GIT:-git}
GREP=${GREP:-grep}
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 09:26:46 -07:00
SED=${SED:-sed}
if [ -f ${1}/.version ]; then
cat ${1}/.version
2012-10-18 20:13:17 +00:00
elif [ -d ${1}/.svn ]; then
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 09:26:46 -07:00
PARTS=`LANG=C svn info ${1} | ${GREP} URL | ${AWK} '{print $2;}' | ${SED} -e 's:^.*/svn/asterisk/::' | ${SED} -e 's:/: :g'`
BRANCH=0
TEAM=0
TAG=0
FEATURE=0
REV=`svnversion -c ${1} | cut -d: -f2`
INTEGRATED=`LANG=C svn pg automerge-propname ${1}`
if [ -z "${INTEGRATED}" ] ; then
INTEGRATED=svnmerge-integrated
fi
BASE=`LANG=C svn pg ${INTEGRATED} ${1} | cut -d: -f1`
if [ "${PARTS}" = "trunk" ] ; then
echo SVN-trunk-r${REV}
exit 0
fi
for PART in $PARTS ; do
if [ ${TAG} != 0 ] ; then
if [ "${PART}" = "autotag_for_be" ] ; then
continue
fi
if [ "${PART}" = "autotag_for_sx00i" ] ; then
continue
fi
RESULT="${PART}"
break
fi
if [ ${BRANCH} != 0 ] ; then
2012-10-18 20:13:17 +00:00
RESULT="${RESULT}-${PART}"
if [ ${FEATURE} != 0 ] ; then
RESULT="${RESULT}-${FEATURE_NAME}"
fi
break
fi
if [ ${TEAM} != 0 ] ; then
if [ -z "${RESULT}" ] ; then
RESULT="${PART}"
else
RESULT="${RESULT}-${PART}"
fi
continue
fi
if [ "${PART}" = "certified" ] ; then
FEATURE=1
FEATURE_NAME="cert"
continue
fi
if [ "${PART}" = "branches" ] ; then
BRANCH=1
RESULT="branch"
continue
fi
if [ "${PART}" = "tags" ] ; then
TAG=1
continue
fi
if [ "${PART}" = "team" ] ; then
TEAM=1
continue
fi
done
if [ ${TAG} != 0 ] ; then
echo ${RESULT}
else
echo SVN-${RESULT}-r${REV}${BASE:+-${BASE}}
fi
2012-10-18 20:13:17 +00:00
elif [ -d ${1}/.git ]; then
if [ -z ${GIT} ]; then
GIT="git"
fi
2012-10-18 20:13:17 +00:00
if ! command -v ${GIT} >/dev/null 2>&1; then
echo "UNKNOWN__and_probably_unsupported"
exit 1
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 09:26:46 -07:00
cd ${1}
2012-10-18 20:13:17 +00:00
# If the first log commit messages indicates that this is checked into
# subversion, we'll just use the SVN- form of the revision.
MODIFIED=""
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 09:26:46 -07:00
SVN_REV=`${GIT} log --pretty=full -1 | ${SED} -n '/git-svn-id:/ s/.*\@\([^ ]*\) .*/\1/p'`
2012-10-18 20:13:17 +00:00
if [ -z "$SVN_REV" ]; then
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 09:26:46 -07:00
# If MAINLINE_BRANCH is already set in the environment, use it.
if [ -z "${MAINLINE_BRANCH}" ] ; then
# Try to retrieve MAINLINE_BRANCH from a local .develvars file first.
# .develvars is keyed by the branch name so we need to get that first.
BRANCH=$(${GIT} symbolic-ref --short HEAD)
if [ -f .develvars ] ; then
MAINLINE_BRANCH=$(${GIT} config -f .develvars --get branch.${BRANCH}.mainline-branch)
fi
# If we didn't find it, see if this is a well-known development branch.
# development/<mainline_branch>/<branchname> or
# devel/<mainline_branch>/<branchname>
if [ "x${MAINLINE_BRANCH}" = "x" ] ; then
MAINLINE_BRANCH=$(echo "${BRANCH}" | ${SED} -n -r -e "s@devel(opment)?/([0-9]+)/.+@\2@p")
fi
# If we didn't find it, get it from .gitreview defaultbranch.
if [ "x${MAINLINE_BRANCH}" = "x" ] ; then
MAINLINE_BRANCH=$(${GIT} config -f .gitreview --get gerrit.defaultbranch)
fi
fi
VERSION=`${GIT} describe --long --always --tags --dirty=M 2> /dev/null`
2012-10-18 20:13:17 +00:00
if [ $? -ne 0 ]; then
if [ "`${GIT} ls-files -m | wc -l`" != "0" ]; then
MODIFIED="M"
fi
# Some older versions of git do not support all the above
# options.
VERSION=`${GIT} rev-parse --short --verify HEAD`${MODIFIED}
2012-10-18 20:13:17 +00:00
fi
echo GIT-${MAINLINE_BRANCH}-${VERSION}
2012-10-18 20:13:17 +00:00
else
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 09:26:46 -07:00
PARTS=`LANG=C ${GIT} log --pretty=full | ${GREP} -F "git-svn-id:" | head -1 | ${AWK} '{print $2;}' | ${SED} -e s:^.*/svn/$2/:: | ${SED} -e 's:/: :g' | ${SED} -e 's/@.*$//g'`
2012-10-18 20:13:17 +00:00
BRANCH=0
TEAM=0
TAG=0
FEATURE=0
if [ "`${GIT} ls-files -m | wc -l`" != "0" ]; then
MODIFIED="M"
fi
for PART in $PARTS ; do
if [ ${TAG} != 0 ] ; then
if [ "${PART}" = "autotag_for_be" ] ; then
continue
fi
if [ "${PART}" = "autotag_for_sx00i" ] ; then
continue
fi
RESULT="${PART}"
break
fi
if [ ${BRANCH} != 0 ] ; then
RESULT="${RESULT}-${PART}"
if [ ${FEATURE} != 0 ] ; then
RESULT="${RESULT}-${FEATURE_NAME}"
fi
break
fi
if [ ${TEAM} != 0 ] ; then
if [ -z "${RESULT}" ] ; then
RESULT="${PART}"
else
RESULT="${RESULT}-${PART}"
fi
continue
fi
if [ "${PART}" = "certified" ] ; then
FEATURE=1
FEATURE_NAME="cert"
continue
fi
if [ "${PART}" = "branches" ] ; then
BRANCH=1
RESULT="branch"
continue
fi
if [ "${PART}" = "tags" ] ; then
TAG=1
continue
fi
if [ "${PART}" = "team" ] ; then
TEAM=1
continue
fi
if [ "${PART}" = "trunk" ]; then
echo SVN-trunk-r${SVN_REV}${MODIFIED}
exit 0
fi
done
if [ ${TAG} != 0 ] ; then
echo ${RESULT}
else
echo SVN-${RESULT##-}-r${SVN_REV}${MODIFIED}
fi
fi
else
echo "UNKNOWN__and_probably_unsupported"
fi