Skip to content

Commit

Permalink
address review comments
Browse files Browse the repository at this point in the history
  • Loading branch information
rem1776 authored and rem1776 committed Jan 26, 2024
1 parent cdece4e commit 4892961
Show file tree
Hide file tree
Showing 2 changed files with 4 additions and 4 deletions.
4 changes: 2 additions & 2 deletions CI.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand All @@ -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`
Expand Down
4 changes: 2 additions & 2 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down

0 comments on commit 4892961

Please sign in to comment.