Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update markdown files for commit policy and ci #1449

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 38 additions & 16 deletions CI.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the seems out of place here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second "the".
To access the netcdf and libyaml the dependencies

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that the

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming you mean same container image here.


cmake flags:
- `-DOPENMP=on`
Expand All @@ -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).
13 changes: 12 additions & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add the link to the conventional commits here?

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it may or must?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps "may be required to" because it really depends on the contribution. If something already has a test, then the developer won't be required to add one.

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).
Expand Down
Loading