@@ -22,7 +22,7 @@ Two maven pom files are found in this folder:
pom.xml --- specifies the to-be-compiled eclipse plugins activated by the given build flags.
pom-bundle-parent.xml --- compilation-specific configuration: currently, it only adds the required openjfx libraries to the tycho classpath.
The `pom.xml` file is the entry point for the compilation, whereas the `pom-bundle-parent.xml` is included from bundle repos (such as af3).
The `pom.xml` file is the entry point for the compilation, whereas the `pom-bundle-parent.xml` is included from bundle repos (such as AF3).
Note that all plugins are build pom-less: this means that no `pom.xml` config file is needed within standard Eclipse plugins. It is only required at the level above. Therefore, a maven extension is specified within the “.mvn” folder within the root of the maven-releng repository.
...
...
@@ -32,11 +32,11 @@ Contains the build specification for the docker container used in the CI Jobs.
## features
contains the tooling kernel and af3 feature as git submodules. Each of these features contains the full set of plugins as of now. However they might be regrouped according to functionality groups in future.
contains the tooling kernel and AF3 feature as git submodules. Each of these features contains the full set of plugins as of now. However they might be regrouped according to functionality groups in future.
## products
contains the af3 phoenix product as git submodule.
contains the AF3 phoenix product as git submodule.
## releng
...
...
@@ -73,7 +73,7 @@ The following build flags are configured:
build.tooling --- activates the compilation of tooling kernel plugins.
build.tests --- runs the junit integration tests on the resulting product.
The build flags are used for a modular build configuration. For instance, another project could only depend on the tooling and implement a product that is totally different from af3.
The build flags are used for a modular build configuration. For instance, another project could only depend on the tooling and implement a product that is totally different from AF3.
The flag _build.tooling_ just produces a p2 update site that can be reused by subsequent builds. This update site is ignored if the flag is specified. thus, the combination of _build.af3_ and _build.tooling_ will not use the tooling update site. An equivalent mechanism is implemented for _build.tests_ that additionally uses an AF3 p2 update site.
## Updating the Docker build container
...
...
@@ -83,15 +83,15 @@ The flag _build.tooling_ just produces a p2 update site that can be reused by su
Whenever a CI job fails, it may be caused by a problematic source code change, a bug in the maven-releng configuration, the docker image, or related to the gitlab CI pipeline. The following pieces of information shall provides hints to debug such issues.
Whenever a CI job fails, it may be caused by a problematic source code change, a bug in the maven-releng configuration, the docker image, or related to the Gitlab CI pipeline. The following pieces of information shall provides hints to debug such issues.
* As a first measure, ensure that the AF3 and Kernel builds in your local AF3 developer installation. Ensure that you are on the branches that you want to test.
* If this test succeeds, do a local AF3 maven build following the instructions for a [local build](https://git.fortiss.org/af3/af3/-/wikis/Setting_up_a_local_build).
* If the build finishes sucessfully, check whether the failure is caused by the docker container configuration. Therefore, on a linux machine, install the gitlab-runner and docker packages and build the docker image locally by executing `docker build -t maven-releng docker/` within your clone of this repository. Afterwards, execute the stage from the CI script that failed by executing
`gitlab-runner exec docker <job-name>`. Please not that pipelines are not supported if executing the gitlab-runner tool locally. Hence you must ensure that all required build artifacts are available in the job to test. For instance, if the test phase fails, the gitlab-ci.yml must be modified to clone all submodules and use all build flags defined in the build job. Finally, if the isse is resolved by a change in the Dockerfile, follow the instructions in the *Structure* section to upload the changes to the gitlab repository. Otherwise, just push the changes of the `gitlab-ci.yml` script.
* If this point is reached, the CI build failure may caused by some pipeline misconfiguration, for instance due to wrong artifact passing. Another likely reason is an outdated docker image in the repositorie's Container Registry.
* If the build finishes sucessfully, check whether the failure is caused by the docker container configuration. Therefore, on a Linux machine, install the `gitlab-runner` and `docker` packages and build the docker image locally by executing `docker build -t maven-releng docker/` within your clone of this repository. Afterwards, execute the stage from the CI script that failed by executing
`gitlab-runner exec docker <job-name>`. Please not that pipelines are not supported if executing the `gitlab-runner` tool locally. Hence you must ensure that all required build artifacts are available in the job to test. For instance, if the test phase fails, `gitlab-ci.yml` must be modified to clone all submodules and use all build flags defined in the build job. Finally, if the isse is resolved by a change in the `Dockerfile`, follow the instructions in the *Structure* section to upload the changes to the Gitlab repository. Otherwise, just push the changes of the `gitlab-ci.yml` script.
* If this point is reached, the CI build failure may caused by some pipeline misconfiguration, for instance due to wrong artifact passing. Another likely reason is an outdated docker image in the repository's Container Registry.
