From cdece4ea0332e624baa5cd34aa33de60b15cbda3 Mon Sep 17 00:00:00 2001 From: rem1776 Date: Wed, 24 Jan 2024 14:15:18 -0500 Subject: [PATCH 1/2] update markdown files for commits and newer ci workflows --- CI.md | 54 ++++++++++++++++++++++++++++++++++--------------- CONTRIBUTING.md | 13 +++++++++++- 2 files changed, 50 insertions(+), 17 deletions(-) diff --git a/CI.md b/CI.md index 89b4db256e..257fc5c34a 100644 --- a/CI.md +++ b/CI.md @@ -7,7 +7,7 @@ Required CI for pull requests are listed first. ## Pull Request CI and checks -### Build libFMS with autotools +### Build libFMS with autotools (GNU) Required GNU build test for all pull requests/pushes. Runs `make distcheck` after configuring via GNU autotools. @@ -32,19 +32,26 @@ libyaml v0.2.5 - `--with-yaml` - `--enable-test-input=/home/unit_tests_input` +### Build libFMS with autotools (intel) + +Required Intel build test for all pull requests. +Runs `make check` after configuring via autotools. + +This runs on an intel-hosted container image from dockerhub. + +To access the netcdf and libyaml the dependencies, it builds and caches the resulting libaries for reuse. +The cache is cleared after not being used for a week. + +`./configure` flags tested: +- `--disable-deprecated-io` +- `--enable-deprecated-io` + ### Build libfms with cmake Required GNU build test for all pull requests/pushes. Runs `make` after configuring via cmake. -Container environment: -gcc v7.3.0 -mpich v3.3a2 -netcdf v4.6.0 -netcdf-fortran v4.4.4 -cmake v3.22.0 - -container hosted at [noaagfdl/ubuntu_libfms_gnu:latest](https://hub.docker.com/r/noaagfdl/ubuntu_libfms_gnu) +This uses the same image as the GNU autotools CI. cmake flags: - `-DOPENMP=on` @@ -58,11 +65,26 @@ Checks code for line lengths, tabs, and trailing whitespace in accordance with the project's [style guide](https://github.com/NOAA-GFDL/FMS/blob/main/CODE_STYLE.md). The action is hosted on github [here](https://github.com/NOAA-GFDL/simple_lint). -## Parallelworks CI -The following CI workflows run on self-hosted runners through the parallelworks platform. -### Pull Request CI libFMS with intel -Optional(does not need to pass to merge) intel build test hosted on the parallelworks platform. -Runs `make check` with intel 18 and 21 compilers for all pull requests. +### Build FMScoupler with FMS + +Runs on pull requests. This workflow pulls in the main branch of the [FMScoupler repository](github.com/noaa-gfdl/FMScoupler), +and then run's its test script using the pull request's version of FMS. + +The coupler's testing script runs a "null model" that uses simple placeholders for the components (ie. atmos_null, ice_null repositories). +It also uses [`mkmf`](github.com/noaa-gfdl/mkmf), a GFDL created build tool to generate it's Makefile's. + +It uses the same docker image as the autotools GNU ci. + +## Miscellaneous + +### Documentation Site +The `github_doc_site.yml` workflow uses the program doxygen to parse our documentation and create a searchable site. +This site is then stored as an artifact, and deployed to github-pages to be accessible at [noaa-gfdl.github.io/FMS]. + + +### Version updates +The `version.yml` workflow appends the -dev to the version number used by autotools upon the creation of a published release. + +It will create a new pull request with the change automatically. -### Tag CI libFMS with AM4 regression -On alpha or beta tag creation, compiles and runs full AM4 model regression testing using the new FMS tag on parallelworks. +Since it's created by a bot account, the pull request will need to be closed and re-opened in order to be merged (due to above CI requirements). diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1ad061ba1c..c449285ac4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -94,14 +94,25 @@ long-term, portability, and the scope of the impact on the code base. Therefore, Modeling Systems does not guarantee that all pull requests will be accepted, even if the changes pass the initial testing phases, and are otherwise correct. +## Commits + +FMS uses the guidelines specified by [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/). + +FMS pull requests are typically ‘squashed’ into one commit. +Descriptive commit messages within PR’s should still be used, and some projects / developers may find it useful to include the file and routine being updated for easy reference. +The commit message on the main branch must follow the guidelines of conventional commits, meaning it includes a ‘type’ prefix (ie. usually fix or feat(ure)) and a footer for any API-breaking changes. +Additionally, commits should include the number of the pull request in parentheses (this is automatically added on github) to allow easier tracking of each commit. + ## Tests -FMS uses TravisCI and gitlab-CI to run build tests for libFMS. Users may create +FMS uses github actions workflows to run build, runtime, and code linting tests for libFMS. Users may create unit tests, code coverage tests, and regression tests for new and existing code in yaml (.yml) files. Github provides a guide (https://help.github.com/en/articles/about-continuous-integration) for implementing CI tests. +The various FMS CI workflows are documented in [CI.md](CI.md) + ## Code Style Code updates should follow the coding style for the project, contained in [CODE_STYLE.md](CODE_STYLE.md). From 48929611b5d53e538664da177f765e9b6c5f68a7 Mon Sep 17 00:00:00 2001 From: rem1776 Date: Fri, 26 Jan 2024 10:50:37 -0500 Subject: [PATCH 2/2] address review comments --- CI.md | 4 ++-- CONTRIBUTING.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/CI.md b/CI.md index 257fc5c34a..2ea8319200 100644 --- a/CI.md +++ b/CI.md @@ -39,7 +39,7 @@ Runs `make check` after configuring via autotools. This runs on an intel-hosted container image from dockerhub. -To access the netcdf and libyaml the dependencies, it builds and caches the resulting libaries for reuse. +To access the netcdf and libyaml dependencies, it builds and caches the resulting libaries for reuse. The cache is cleared after not being used for a week. `./configure` flags tested: @@ -51,7 +51,7 @@ The cache is cleared after not being used for a week. Required GNU build test for all pull requests/pushes. Runs `make` after configuring via cmake. -This uses the same image as the GNU autotools CI. +This uses the same container image as the GNU autotools CI. cmake flags: - `-DOPENMP=on` diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c449285ac4..5769c50323 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -100,12 +100,12 @@ FMS uses the guidelines specified by [conventional commits](https://www.conventi FMS pull requests are typically ‘squashed’ into one commit. Descriptive commit messages within PR’s should still be used, and some projects / developers may find it useful to include the file and routine being updated for easy reference. -The commit message on the main branch must follow the guidelines of conventional commits, meaning it includes a ‘type’ prefix (ie. usually fix or feat(ure)) and a footer for any API-breaking changes. +The commit message on the main branch must follow the guidelines of [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/), meaning it includes a ‘type’ prefix (ie. usually fix or feat(ure)) and a footer for any API-breaking changes. Additionally, commits should include the number of the pull request in parentheses (this is automatically added on github) to allow easier tracking of each commit. ## Tests -FMS uses github actions workflows to run build, runtime, and code linting tests for libFMS. Users may create +FMS uses github actions workflows to run build, runtime, and code linting tests for libFMS. Users may be required to create unit tests, code coverage tests, and regression tests for new and existing code in yaml (.yml) files. Github provides a guide (https://help.github.com/en/articles/about-continuous-integration) for