-
Notifications
You must be signed in to change notification settings - Fork 25
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
Add github actions workflow to test SRWA build #352
Add github actions workflow to test SRWA build #352
Conversation
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.
@robgonzalezpita This is nice work. I left some comments/suggestions below.
If corresponding branch is not found in SRWA repository, checkout the base branch. Change how ./build.sh is printed to stdout.
…t github.refs for debugging on web interface
…nd branch name in the SRWA, add final job to display build status in web interface
84a1c06
to
b22ff0f
Compare
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.
I believe I've addressed all of the old requested changes. Please re-review and suggest any new changes.
# (Cloning repositories outside of the GITHUB_WORKSPACE directory is not supported with actions/checkout@v3, so it needs to be moved into the parent directory seperately) | ||
# The SRWA is cloned within the GITHUB_WORKSPACE (default location of where 'run' commands are executed ), we need to move its location up one directory, as the regional_workflow is nested within the SRWA. | ||
Clone_SRWA: | ||
name: Clone SRWA and move into parent directory |
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.
Why does it need to move up one directory? Can you not clone SRW where you want it, and then clone regional_workflow inside that clone using the path
option for both?
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.
@christinaholtNOAA, you pose some great questions, and this a much better approach. I updated the GHA workflow to clone SRW and place the regional_workflow inside of that clone using the path
option.
DESCRIPTION OF CHANGES:
Currently, there are no Continuous Integration (C.I.) tests for this repository. C.I. tests are considered a software engineering best practice, with numerous benefits to developers as well as the code-base. This PR adds the first step in implementing a C.I. pipeline (building the ufs-srweather-app). Forthcoming work will add another GitHub Actions workflow file which will automate the running of Workflow End To End tests.
TESTS CONDUCTED:
A build test accomplished via the GHA workflow file was done on an AWS Parallel cluster configured as a self-hosted runner with all of the necessary dependencies, including
hpc-stack
with versions matched as closely as possible to srw_common (different patch of g2). As versions of dependent libraries change, the self-hosted runner will need to be updated, reflecting those changes.A successful GitHub actions workflow run has been accomplished, on my fork. Once a GitHub Actions Self-Hosted runner is configured and assigned to the NOAA-GSL fork, the proposed GitHub Actions Workflow will run on it.
DEPENDENCIES:
This GitHub Action Workflow is run on a self-hosted runner, which must be assigned to this repository. A machine configured as a Github Actions self-hosted runner is necessary to run this workflow.
PR #152 for the ufs-srweather-app is a concurrent pull request. While not a dependency, once that one has been accepted, the workflow can be simplified in utilizing those changes.
DOCUMENTATION:
PR #152 in the
ufs-srweather-app
includes adocs/UsersGuide/source/ContinuousIntegration.rst
file.CONTRIBUTORS:
@christinaholtNOAA @christopherwharrop-noaa @venitahagerty