About SetupEnv

SetupEnv creates an environment for the unit tests. It reads the Project.toml of the project and installs all QED dependencies as development version from the current dev branch by default. All other dependencies are normally installed. SetupEnv also allows to install QED dependencies from other repositories and branches.

On a local system, you can set the environment variable CI_UNIT_PKG_URL_<QED_package>=https://github.com/User/<QED_package>#<branch>. For example, if I want to use my fork of QEDbase and the feature branch fooFunction I have to set the environment variable CI_UNIT_PKG_URL_QEDbase=https://github.com/SimeonEhrig/QEDbase.jl.git#fooFunction.
In the CI, the dependency can set via commit message:

Example Git commit message:

 Add function bar

- function bar uses the function foo from the QEDbase packge 

 CI_UNIT_PKG_URL_QEDbase: https://github.com/SimeonEhrig/QEDbase.jl.git#fooFunction

Pipeline behavior

The pipeline has two stages for unit test. The first stage does the actual unit tests. If the stages passes, you code is fine. The second stage checks, if SetupEnv use custom URLs for QED packages. If this happens, the test will fail. The reason is, that no code should be merged, which rely on non merged functions. The solution is merging the code in the depending package first and than trigger the CI with CI_UNIT_PKG_URL_<package> in the message again.

Local unit tests

Local unit tests are enable in the .gitlab-ci.yml. Actual QED.jl will not have functionality, but with the unit tests, we can test the functionality of the SetupEnv.

unit testing in sub packages

Sub packages needs to clone this repository to get the SetupEnv tool, see https://github.com/QEDjl-project/QEDfields.jl/pull/3

Documentation

Documentation is coming, when the integration tests are implement. I decided to split up the unit and integration tests in two separate PR for better review. Compare to it, it is better to write the documentation of the unit and integration test together. So, the unit test documentation is coming together with the integration test PR. A initial version can be found here: https://github.com/SimeonEhrig/GitlabCIMain/blob/master/docs/src/index.md

SimeonEhrig commented 1 year ago

Testing the PR

To test the PR, we need an unconventional setup. I added unit tests in the QEDfields project. Afterwards I created a feature branch, which implements an new function bar with a dependency to the function QEDbase::foo(). foo is not merged in dev branch and exists only on a feature branch on my fork. Like expected, the unit test fails, because the CI test against the dev branch, see this commit. In a second commit, I added CI_UNIT_PKG_URL_QEDbase: https://github.com/SimeonEhrig/QEDbase.jl.git#fooFunction at the end of the commit message. Now the CI is testing the unit tests with my feature branch and the CI passes.

In a third commit, I added the unit test dependency verification. Therefore the unit tests passes, but the CI failes.