-
Notifications
You must be signed in to change notification settings - Fork 135
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
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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` | ||
|
@@ -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). |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it may or must? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). | ||
|
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that
the