# to).
# Add a top-level target that builds everything related to the webpage,
- # for Jenkins (and possibly others) to use
+ # for CI (and possibly others) to use
add_custom_target(webpage ${_webpage_target_properties}
COMMENT "Building webpage"
VERBATIM)
.. cmake:: GMX_BUILD_FOR_COVERAGE
- Special variable set ``ON`` by Jenkins when doing a build for the coverage
+ Special variable set ``ON`` by CI when doing a build for the coverage
job. Allows the build system to set options to produce as useful coverage
metrics as possible. Currently, it disables all asserts to avoid them
showing up as poor conditional coverage.
.. cmake:: GMX_COMPILER_WARNINGS
If set ``ON``, various compiler warnings are enabled for compilers that
- Jenkins uses for verification.
+ CI uses for verification.
Defaults to ``OFF`` when building from a source tarball so that users
- compiling with versions not tested on Jenkins are not exposed to our rather
+ compiling with versions not tested in CI are not exposed to our rather
aggressive warning flags that can trigger a lot of warnings with, e.g., new
versions of the compilers we use.
When building from a git repository, defaults to ``ON``.
Runs a custom Python checker script to check for various source-level
issues. Uses Doxygen XML documentation as well as rudimentary parsing of
some parts of the source files.
- This target is used as part of the Jenkins documentation job.
+ This target is used as part of the CI.
All CMake code is currently in :file:`docs/doxygen/`.
See :doc:`gmxtree`.
completion
doxygen-*
Targets that run Doxygen to generate the documentation.
The ``doxygen-all`` target runs as part of the ``webpage`` target, which in
- turn runs as part of the Jenkins documentation job.
+ turn runs as part of the CI.
All CMake code is in :file:`docs/doxygen/`.
See :doc:`doxygen`.
gmxapi-cppdocs
webpage
Collection target that runs the other documentation targets to generate the
full set of HTML (and linked) documentaion.
- This target is used as part of the Jenkins documentation job.
+ This target is used as part of the CI.
All CMake code is in :file:`docs/`.
webpage-sphinx
Runs Sphinx to generate most content for the HTML documentation (the set of
Setting up login credentials with gitlab
----------------------------------------
-You will need a public ssh key. If you were using Gerrit, you probably
-already have one and you can ignore the first line::
+You will need a public ssh key::
ssh-keygen -t rsa -C "your.email@address.com"
cat ~/.ssh/id_rsa.pub
.. seealso:: :ref:`issue workflow` for use of Status labels in Issue management.
-Moving code from gerrit to gitlab
-=================================
-
-Create a local repository that is connected to both Gerrit and Gitlab::
-
- git clone git@gitlab.com:gromacs/gromacs.git -o gitlab gromacs-migrate
- cd gromacs-migrate/
- git remote add gerrit ssh://<gerrit-username>@gerrit.gromacs.org/gromacs.git
- git fetch --all
-
-Checkout the current gitlab master::
-
- git checkout gitlab/master
-
-Go to your commit on https://gerrit.gromacs.org/ , select Download->Cherry-Pick
-
-``git fetch "https://gerrit.gromacs.org/gromacs" refs/changes/XX/YYYY/ZZ && git cherry-pick FETCH_HEAD``
-
-Resolve conflicts, if any. If you need to do further changes to your patch,
-feel free to ammend them at this point. Remove the Gerrit commit-id line from
-the bottom of the commit message, but keep the issue (ex. redmine) references -
-they match the gitlab issues.
-
-Do not forget to run clang-format script (``admin/clang-format.sh update -f --rev=HEAD^``)
-and copyright script (``admin/copyright.sh update -f --rev=HEAD^``).
-
-When ready, move the patch to a new branch::
-
- git branch <branch-name>
-
-Make sure to select a unique branch name that it is easy for you to connect to
-a specific patch. You will need it later to make changes to your merge request.
-Keep in mind that your branch name is going to be exposed to everyone while
-your patch is under review. Push the branch to GitLab::
-
- git push gitlab <branch-name>
-
-Go to https://gitlab.com/gromacs/gromacs and create a merge request.
-Copy-paste your commit message from Gerrit into the merge request description
-text box, use the first line as a title. If your branch has only one commit,
-this will be done automatically. Add "From: https://gerrit.gromacs.org/#/c/gromacs/+/XXXXX/"
-to the end of your commit message.
-Select "Delete source branch when merge request is accepted." check-box.
-Select "Squash commits when merge request is accepted" check-box.
-Check and that squash commit message is correct. If necessary, update it.
-
-If your change in Gerrit depends on another Gerrit change:
-
-Make sure that you transfer the parent change to GitLab first.
-When transferring the child change, specify the parent in the "Merge request dependencies" text field.
-In GitLab menu, go to Repository -> Compare. Select the branch that correspond
-to the child change as a Source in the drop-down menu, choose parent change as
-the Target. Click Compare button and copy the link from the browser address bar.
-Add "Compare to the parent: https://gitlab.com/gromacs/gromacs/-/compare/PARENT_BRANCH...CHILD_BRANCH"
-to the description of the merge request. You will have to keep this dependency
-up to date for the link to work properly. For example, if you update the parent,
-you will need to merge its branch to the child branch right away.
-Otherwise your recent updates will show up in comparison.
-
-
More git tips
=============
NO_FORMAT_CHECK=1 git commit -a
-You can also run ``git commit --no-verify``, but that also disables other hooks,
-such as the Change-Id ``commit-msg`` hook used by Gerrit.
+You can also run ``git commit --no-verify``, but that also disables other hooks.
Note that when you run ``git commit --amend``, the hook is only run for the
changes that are getting amended, not for the whole commit. During a rebase,
We also need some form of automated high-level test of your code,
because people who do not understand its details need to be able to
change the infrastructure that you depend on. |Gromacs| uses
- automated continuous-integration testing implemented by our
- :doc:`jenkins <jenkins>` server, and we need quick feedback about whether your
+ automated continuous-integration testing in :doc:`GitLab <gitlab-ci>`,
+ and we need quick feedback about whether your
code would be affected by a proposed change. This means the users of
your feature can continue to do good science based upon trustworthy
results generated by new versions of |Gromacs| released after you've
This is most easily invoked through a ``check-source`` target in the build system.
The script also checks that documentation for a header matches its use in the
source code (e.g., that a header documented as internal to a module is not
- actually used from outside the module). These checks are run in Jenkins as
- part of the Documentation job. Details for the custom checker are on a
- separate page (common for several checkers): :doc:`gmxtree`.
+ actually used from outside the module). These checks are run in CI.
+ Details for the custom checker are on a separate page (common for several
+ checkers): :doc:`gmxtree`.
module dependency graphs
|Gromacs| uses a custom Python script to generate an annotated dependency
Building the documentation
--------------------------
-If you simply want to see up-to-date documentation, you can go to
-http://jenkins.gromacs.org/job/Documentation_Nightly_master/javadoc/html-lib/index.xhtml
-to see the documentation for the current development version.
-Jenkins also runs Doxygen for all changes pushed to Gerrit for
-release-5-0 and master branches, and the
-resulting documentation can be viewed from the link posted by Jenkins. The
-Doxygen build is marked as unstable if it introduces any Doxygen warnings.
+If you want to see up-to-date documentation, you can download artifacts from
+the ``webpage`` job of the latest scheduled pipeline for a corresponding branch
+(https://gitlab.com/gromacs/gromacs/-/pipelines?page=1&scope=all&source=schedule).
+CI also runs Doxygen for all changes pushed to GitLab for
+release and master branches, and the resulting documentation can be
+found in the artifacts of the corresponding ``webpage`` job.
+The Doxygen job will fail if it introduces any Doxygen warnings.
You may need to build the documentation locally if you want to check the
results after adding/modifying a significant amount of comments. This is
The checks are run as part of a single ``check-source`` target, but are described
in separate sections below. In addition to printing the issues to ``stderr``,
the script also writes them into ``docs/doxygen/check-source.log`` for later
-inspection. Jenkins runs the checks as part of the Documentation job, and the
-build is marked unstable if any issues are found.
+inspection. CI runs the checks as part of all pipelines and CI will fail
+if any issues are found.
For correct functionality, the scripts depend on correct usage of Doxygen
annotations described in :doc:`doxygen`, in particular the visibility and
Automation and Infrastructure
=============================
-Through the 2020 release, automated testing and documentation builds are
-performed by a Jenkins installation. With the resolution of :issue:`3272`,
-|Gromacs| is transitioning to GitLab and GitLab Runner.
+Starting from 2020 release, automated testing and documentation builds are
+performed by GitLab and GitLab Runner.
.. toctree::
:maxdepth: 2
Not installed headers are allowed to include ``config.h``. Cyclic include dependencies
prevent this, and must be avoided because of this. This is best guaranteed
by including every header in some source file as the first header,
-even before ``config.h``. This is partly enforced by :doc:`gmxtree`,
-which is run by Jenkins and votes accordingly in Gerrit.
+even before ``config.h``.
Code inside the library should not unnecessarily include headers. In
particular, headers should not include other headers if a forward
functionality exposed outside the module. Some of the tests, in particular for
higher-level modules, are more like integration tests, and test the
functionality of multiple modules.
-Shared code used to implement the tests is in ``src/external/gmock-1.7.0/`` and
+Shared code used to implement the tests is in ``src/external/googletest/`` and
``src/testutils/`` (see below).
The tests are built if ``BUILD_TESTING=ON`` (the default) and
When executed using CTest, the tests produce XML output in
``Testing/Temporary/``, containing the result of each test as well as failure
-messages. This XML is used by Jenkins for reporting the test status for
+messages. This XML is used by GitLab CI for reporting the test status for
individual tests. Note that if a test crashes or fails because of an assert or
-a gmx_fatal() call, no XML is produced for the binary, and Jenkins does not
+a gmx_fatal() call, no XML is produced for the binary, and CI does not
report anything for the test binary. The actual error is only visible in the
console output.
the `Google Test Primer`_ for an introduction.
Some tests also use `Google Mock`_, which provides a framework for creating
mock implementations of C++ classes. Both components are included in the
-source tree under ``src/external/gmock-1.7.0/``, and are compiled as part of the
+source tree under ``src/external/googletest/``, and are compiled as part of the
unit test build.
``src/testutils/`` contains |Gromacs|-specific shared test code. This includes
should take seconds instead of minutes to run, so that no one needs to
hesitate before running the tests after they have done some changes.
Long-running tests should go somewhere else than in the unit test set.
- Note that Jenkins runs many of the tests under Valgrind, so heavy tests are
- going to slow down also that part of the verification.
+ Note that CI will run the tests in several build configuration and
+ slow tests will significantly slow down the pipelines and can even cause
+ them to timeout.
- Try to produce useful messages when a test assertion fails. The assertion
message should tell what went wrong, with no need to run the *test itself*
under a debugger (e.g., if the assertion is within a loop, and the loop
unit testing (CTest)
|Gromacs| uses a unit testing framework based on Google C++ Testing
- Framework (gtest) and CTest. All unit tests are automatically run on Jenkins
+ Framework (gtest) and CTest. All unit tests are automatically run in GitLab CI
for each commit.
Details can be found on a separate page on :doc:`testutils`.
# Only recent versions of git support pattern matching rules that would allow
# the first to be conveniently specified in the main .gitattributes file.
-* -filter -gmx-doxygen
-gmock-1.7.0/CMakeLists.txt filter=copyright
+* -filter -gmx-doxygen
\ No newline at end of file
#
# This file is part of the GROMACS molecular simulation package.
#
-# Copyright (c) 2014,2015,2017,2018,2019,2020, by the GROMACS development team, led by
+# Copyright (c) 2014,2015,2017,2018,2019,2020,2021, by the GROMACS development team, led by
# Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
# and including many others, as listed in the AUTHORS file in the
# top-level source directory and at http://www.gromacs.org.
)
gmx_register_gtest_test(GmxPreprocessTests gmxpreprocess-test SLOW_TEST)
-# Currently these can be slow to run in Jenkins, so they are in
+# Currently these can be slow to run in CI, so they are in
# several test binaries.
set(exename pdb2gmx1-test)
if (minimizer == "l-bfgs" && getNumberOfTestMpiRanks() > 1)
{
// Ideally we would use this death test, but it is not
- // stable enough in Jenkins, so we just skip it.
+ // stable enough in CI, so we just skip it.
// EXPECT_DEATH_IF_SUPPORTED(runner_.callMdrun(mdrunCaller),
// "L-BFGS minimization only supports a single rank");
return;
biod.pnpi.spb.ru / alexxy / gromacs.git / commitdiff