[Asterisk-code-review] build: Refactor the earlier "basebranch" commit (asterisk[development/16/geolocation])

[George Joseph]

Attention is currently required from: George Joseph.
Hello Friendly Automation, 

I'd like you to reexamine a change. Please visit

    https://gerrit.asterisk.org/c/asterisk/+/18065

to look at the new patch set (#3).

Change subject: build: Refactor the earlier "basebranch" commit
......................................................................

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
---
M .gitignore
M build_tools/make_version
M tests/CI/buildAsterisk.sh
M tests/CI/installAsterisk.sh
4 files changed, 45 insertions(+), 8 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/65/18065/3
-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/18065
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: development/16/geolocation
Gerrit-Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
Gerrit-Change-Number: 18065
Gerrit-PatchSet: 3
Gerrit-Owner: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Attention: George Joseph <gjoseph at digium.com>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20220221/1e109edb/attachment.html>