2006-04-24 17:11:45 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
2013-04-08 18:24:50 +00:00
|
|
|
GIT=${GIT:-git}
|
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}
|
2023-05-03 11:37:57 -04:00
|
|
|
AWK=${AWK:-awk}
|
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
|
|
|
|
2006-04-24 17:11:45 +00:00
|
|
|
if [ -f ${1}/.version ]; then
|
2009-03-12 01:33:04 +00:00
|
|
|
cat ${1}/.version
|
2023-03-13 13:35:07 -06:00
|
|
|
exit 0
|
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2023-03-13 13:35:07 -06:00
|
|
|
if [ ! -d ${1}/.git ]; then
|
|
|
|
echo "UNKNOWN__and_probably_unsupported"
|
|
|
|
exit 0
|
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2023-03-13 13:35:07 -06:00
|
|
|
if [ -z ${GIT} ]; then
|
|
|
|
GIT="git"
|
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2023-03-13 13:35:07 -06:00
|
|
|
if ! command -v ${GIT} >/dev/null 2>&1; then
|
|
|
|
echo "UNKNOWN__and_probably_unsupported"
|
|
|
|
exit 1
|
|
|
|
fi
|
2012-06-06 17:22:11 +00:00
|
|
|
|
2023-03-13 13:35:07 -06:00
|
|
|
GITCHECK=$(${GIT} describe --always 2>/dev/null || echo gitfail 2>/dev/null)
|
|
|
|
if [ "x${GITCHECK}" = "xgitfail" ]; then
|
|
|
|
echo "UNKNOWN__git_check_fail"
|
|
|
|
exit 1
|
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2023-03-13 13:35:07 -06:00
|
|
|
cd ${1} || exit 1
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2023-03-13 13:35:07 -06:00
|
|
|
MODIFIED=""
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2023-03-13 13:35:07 -06: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 2>/dev/null)
|
|
|
|
if [ -f .develvars ] ; then
|
|
|
|
MAINLINE_BRANCH=$(${GIT} config -f .develvars --get branch.${BRANCH}.mainline-branch)
|
2012-10-18 20:13:17 +00:00
|
|
|
fi
|
2017-12-22 09:23:22 -05:00
|
|
|
|
2023-03-13 13:35:07 -06:00
|
|
|
# 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")
|
2012-10-18 20:13:17 +00:00
|
|
|
fi
|
2022-06-01 20:03:06 -06:00
|
|
|
|
2023-05-03 11:37:57 -04:00
|
|
|
# If we didn't find it, get it from configure.ac.
|
2023-03-13 13:35:07 -06:00
|
|
|
if [ "x${MAINLINE_BRANCH}" = "x" ] ; then
|
2023-05-03 11:37:57 -04:00
|
|
|
MAINLINE_BRANCH=$(${AWK} '/AC_INIT/ { print substr($2, 2, length($2) - 3) }' configure.ac)
|
2022-06-01 20:03:06 -06:00
|
|
|
fi
|
2023-03-13 13:35:07 -06:00
|
|
|
fi
|
2022-06-01 20:03:06 -06:00
|
|
|
|
2023-03-13 13:35:07 -06:00
|
|
|
VERSION=`${GIT} describe --long --always --tags --dirty=M 2> /dev/null`
|
|
|
|
if [ $? -ne 0 ]; then
|
|
|
|
if [ "`${GIT} ls-files -m | wc -l`" != "0" ]; then
|
|
|
|
MODIFIED="M"
|
2012-10-18 20:13:17 +00:00
|
|
|
fi
|
2023-03-13 13:35:07 -06:00
|
|
|
# Some older versions of git do not support all the above
|
|
|
|
# options.
|
|
|
|
VERSION=`${GIT} rev-parse --short --verify HEAD`${MODIFIED}
|
2006-04-24 17:11:45 +00:00
|
|
|
fi
|
2023-03-13 13:35:07 -06:00
|
|
|
echo GIT-${MAINLINE_BRANCH}-${VERSION}
|