on-demand GitHub action which runs every quickbuild.sh in DART

[hkershaw-brown]

Description:

On demand github action to run every quickbuild.sh in DART
Uses container with dart dependencies hdfeos2, hdf4, hdf5, rttov12
Takes ~4 minutes

Fixes issue

Github version the build_everything developer tests #593

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Documentation changes needed?

• My change requires a change to the documentation.
  • I have updated the documentation accordingly.

Tests

Run the action on main branch of your fork.

Checklist for merging

• Updated changelog entry
• Documentation updated
• Update conf.py

Checklist for release

• Merge into main
• Create release from the main branch with appropriate tag
• Delete feature-branch

Testing Datasets

• Dataset needed for testing available upon request
• Dataset download instructions included
• No dataset needed

[mjs2369]

@hkershaw-brown I've reviewed and tested your code by using your new action on my fork. The action reported three failures from the quickbuilds of the following three obs converters:

• Gps

/usr/bin/ld: cannot find ../../NCEP/prep_bufr/lib/bufrlib.a: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:227: convert_cosmic_gps_cdf] Error 1

• GSI2DART

  173 |     call mpi_bcast(sprd_ob,nobs_tot,mpi_real4,0,mpi_comm_world,ierr)
      |                   1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (REAL(4)/INTEGER(4)).

• Var
  Fatal Error: Cannot open module file 'da_constants.mod' for reading at (1): No such file or directory

While some failures are to be expected, it causes the entire action to report back as a failure.

Is this the behavior we want for this action, or is there a way to set which jobs we expect to fail and compare against the results so that the whole check passes?

[hkershaw-brown]

I'm kind of digging the failure as a mark of shame, but you're right you have to check the annotations. Do you think skipping the expected fails is ok (not run them in the matrix)?

[mjs2369]

I'm kind of digging the failure as a mark of shame, but you're right you have to check the annotations. Do you think skipping the expected fails is ok (not run them in the matrix)?

@hkershaw-brown I think that sounds like a good plan. I'm just a little confused on how we would go about setting the expected fails to have them not run in the matrix? Just like how you are currently skipping the template model, but for the three failing obs converters instead?

for item in "${files_to_process[@]}"; do
            if [[ $item == *"template"* ]]; then
              continue  # template model not for compiling
            fi

Also side note is that GSI2DART compiles with the use of -fallow-argument-mismatch

[hkershaw-brown]

@hkershaw-brown I think that sounds like a good plan. I'm just a little confused on how we would go about setting the expected fails to have them not run in the matrix? Just like how you are currently skipping the template model, but for the three failing obs converters instead?

for item in "${files_to_process[@]}"; do
            if [[ $item == *"template"* ]]; then
              continue  # template model not for compiling
            fi

yup, just skip them.

[hkershaw-brown]

skipping known failures, using -fallow-argument-mismatch for GSI2DART 21399b9

[mjs2369]

@hkershaw-brown I've reviewed your updates and everything looks good. I went ahead and ran the updated workflow on my fork and it passed now that we have skipped the known failures. Approved