1 # Build Bonita from sources
3 [![Linux build](https://img.shields.io/travis/Bonitasoft-Community/Build-Bonita/master?label=Linux%20build&logo=travis)](https://travis-ci.org/Bonitasoft-Community/Build-Bonita)
5 [![MacOS and Windows build](https://github.com/Bonitasoft-Community/Build-Bonita/workflows/MacOS%20and%20Windows%20Build/badge.svg)](https://github.com/Bonitasoft-Community/Build-Bonita/actions)
10 A bash script is provided to build the whole Bonita Community Edition solution from sources publicly available.
12 It clones Git repositories and build all Bonita components in the right order to let you generate the Bonita Bundle and
18 - Disk space: around 15 GB free space. Around 4 GB of dependencies will be downloaded (sources, 3rd party dependencies,
19 ...). A fast internet connection is recommended.
20 - OS: Linux, MacOS and Windows (see test environments list below)
21 - Java: Oracle/OpenJDK Java 8 (⚠ you cannot use Java 11 to build Bonita).
26 1. Clone this repository
27 1. Checkout the [branch/tag](#branches-and-tags) related to the Bonita version you want to build
28 1. Run `bash build-script.sh` in a terminal (on Windows, use git-bash as terminal i.e. the bash shell included with Git for Windows)
29 1. Once finished, the following binaries are available
30 1. Bonita Studio (aka Bonita Development Suite): `bonita-studio/all-in-one/target` (only zip archive, no installer)
31 1. Bonita Bundle (aka Bonita Runtime): `bonita-distrib/tomcat/target`
34 - If you want to make 100% sure that you do a clean build from scratch, run the following commands:
36 rm -rf ~/.m2/repository/org/bonitasoft/
37 rm -rf ~/.m2/repository/.cache
38 rm -rf ~/.m2/repository/.meta
39 rm -rf ~/.gradle/caches
40 find -type d -name ".gradle" -prune -exec rm -rf {} \;
41 find -type d -name target -prune -exec rm -rf {} \;
43 - No tests are run by the script (at least no back end tests). If you want to run some tests, go to the directory
44 related to the Bonita component you want to test, and follow instructions (generally available in README file)
45 - The script does not produce Studio installers (required license for proprietary software).
50 CI builds are run on push to master/dev branches and Pull Requests (see badges on top of this page)
51 - Linux: Ubuntu 18.04 (Travis CI)
52 - MacOS: Catalina (GitHub Actions)
53 - Windows: Windows Server 2019 DataCenter (GitHub Actions)
58 If you face any issue with this build script or for any question, please report it on the [build-bonita GitHub issues tracker](https://github.com/Bonitasoft-Community/Build-Bonita/issues).
60 You can also ask for help on [Bonita Community forum](https://community.bonitasoft.com/questions-and-answers).
63 ## <a name="branches-and-tags"></a> Branches and Tags
65 The use of `Build-Bonita` branch or tag depends of the Bonita version you want to build.
67 | Bonita version | Build-Bonita branch or tag |
69 | latest maintenance version | `master` branch |
70 | old version | related tag (see the [tags](#tags) section below) |
71 | next Bonita GA version | `dev` branch |
74 - `Build-Bonita` currently does not provide support for building Bonita SNAPSHOT versions aka next maintenance or
75 development versions. See [#41](https://github.com/Bonitasoft-Community/Build-Bonita/issue/41) for such a support
80 `Build-Bonita` uses the same branch names as the Bonita repositories
81 - `master` for latest available GA or maintenance version. It also contains latest build improvements related to the
82 solution provided by `Build-Bonita`
83 - `dev` for next Bonita version while developments are in progress
88 Tags are only available to build Bonita GA (i.e. 7.9.0, 7.10.0, ....) or maintenance (i.e. 7.7.5, 7.9.4, ....) versions,
89 not for development versions.
91 ### <a name="tag-scheme"></a> Tag scheme
92 - prior Bonita 7.10, `Build-Bonita` tags exactly match the Bonita version
93 - as of Bonita 7.10, tags use the `<bonita_version>-<increment>` like `7.10.0-1`. This allows to track improvements or
94 bug fixes applied to `Build-Bonita` for a given Bonita version
98 | Bonita version | Build-Bonita tag |
100 | 7.10.1 | 7.10.1-1, 7.10.1-2, .... |
101 | 7.10.0 | 7.10.0-1, 7.10.0-2, .... |
106 # Developing on Build-Bonita
108 The following is for contributors to this repository.
110 Notice that a lot of actions are manual, so if it's becoming boring for you, fill an issue to discuss about it, then
111 provide a Pull Request to automate this and simplify our life
113 ## Add support for a new version
115 Notice that most of the actions described below can be done directly using the GitHub website, for instance
117 - branch and pull request creation
119 See [GitHub help](https://help.github.com/en/github/managing-files-in-a-repository/editing-files-in-your-repository) for
122 ### Bonita maintenance version
124 - from GitHub interface, edit `build-script.sh`on `master` branch (you can follow [GitHub help](https://help.github.com/en/github/managing-files-in-a-repository/editing-files-in-your-repository))
125 - update the `build-script.sh` file and update the `BONITA_VERSION` variable
126 - propose file changes by creating a new branch, for instance `maintenance_7.10.2`
127 - [create a Pull Request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request) targeting `master`
128 - wait for build to pass, this should work without any other modifications
129 - [merge the Pull Request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request) after successful build
131 ### Bonita development version
133 - create a new branch starting from the `dev` branch, for instance `dev_7.11.0.W10`
134 - update the `build-script.sh` file and update the `BONITA_VERSION` variable
135 - [create a Pull Request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request) targeting the `dev` branch
136 - wait for build to run
137 - failures often happen because of new components to be added or removed, build options of some components to be updated
138 - try to fix, then commit and iterate until build pass
139 - see [#32](https://github.com/Bonitasoft-Community/Build-Bonita/pull/32) or
140 [#48](https://github.com/Bonitasoft-Community/Build-Bonita/pull/48) for instance
141 - [merge the Pull Request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request) after successful build
144 ### Merging master and dev branches
146 Follow the same lifecycle as Bonita component repositories. Merge are currently done manually by `Build-Bonita`
148 - `master` --> `dev`: all the time, especially after adding support for a new maintenance version. Allow to get new
149 improvements applied to maintenance versions, avoid subsequent merge conflicts, ...
150 - `dev` --> `master`: on GA release, `master` is going to become the maintenance branch for the new Bonita released
151 version. It is highly advised to do the merge in a dedicated branch as some issue occurred at that stage in the past
152 - first, ensure that `master` has been merged into`dev`
153 - create a new `bonita_7.10.0_GA` branch starting from `master` branch
154 - merge `dev` into `bonita_7.10.0_GA`
155 - [create a Pull Request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request) from `bonita_7.10.0_GA` targeting the `master` branch
156 - [merge the Pull Request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request) into `master` when the build passed (eventually after fixing any issues related to the merge)
162 - a new Bonita version (GA or maintenance) is supported by `Build-Bonita`
163 - significant improvements have been made in the `Build-Bonita` build script for the latest supported Bonita version
165 ### Create a GitHub release
167 A new release can be create by following the [GitHub help](https://help.github.com/en/github/administering-a-repository/managing-releases-in-a-repository#creating-a-release)
168 - for `Tag version`, use a value that follows the [Tag Scheme](#tag-scheme). The tag will be created when the release
171 - usually, keep the `master` branch except if new commits that you don't want to integrate for the release are already
172 available in the branch
173 - in that case, choose a dedicated commit
174 - **important**: ensure that the build to pass on the chosen branch or commit used to create the release