Commit Graph

5 Commits

Author SHA1 Message Date
George Joseph
13177a310d 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-28 08:46:14 -06:00
George Joseph
c86c0973ff CI: Add install-headers to the install make targets
The testsuite actually needs the headers installed to run
it's self_test.

Change-Id: Ice41d331131b876ad4a9c056085fe6aac34b32b2
2019-07-19 07:40:57 -06:00
George Joseph
914b9e1934 CI: Add optional uninstall step before installing asterisk
Change-Id: I7dedf1e925eafc3a0adf01dd9dfbe44eb642aab7
2018-07-30 08:44:25 -05:00
George Joseph
33a84745d0 CI: Add Asterisk Gates
Change-Id: I7e2467f9120812551238d8005deb97f965279205
2018-07-12 15:34:14 -06:00
George Joseph
b302ee6bd5 CI: Initial commit for moving CI into source repo
Create tests/CI directory and add files used by Jenkins to
build and test Asterisk.

With this commit, Jenkins will run the Asterisk Unit Tests using
the Jenkinsfile at tests/CI/unittests.jenkinsfile.  Bash scripts
to do the actual building and testing are also in the same directory.
Output is placed in tests/CI/output so that directory has been
added to .gitignore.

Change-Id: I9448065465e6de2b878634510ace8fd1ef378608
2018-07-11 05:19:48 -06:00