llnl / llnl/scr

create gitlab test for libyogrt

Open
#269 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

testing
Dominant language
C
Stars
108
Forks
37
PR merge metrics
No merged PRs in 30d

Description

We should also add a gitlab test for libyogrt. Something like:

1) submit a job with a 5 minute time limit
2) check that a call to libyogrt returns a remaining time value that is 5 minutes or less
3) wait ~30 seconds, call libyogrt again and check that time remaining has decreased by something close to 30 seconds

We'd want tests for both SLURM and LSF.

Ideally, we should test all of:
1) our existing system installs
2) spack install of libyogrt, e.g., ``spack install libyogrt scheduler=slurm``
3) autotools install of libyogrt

For an example code that calls libyogrt:
```
# install libyogrt from spack
bin/spack install libyogrt

# test program
>>: cat grt.c
#include
#include
#include "yogrt.h"
int main (int argc, char* argv[])
{
long int secs = yogrt_remaining();
printf("%lu\n", secs);
return 0;
}

# allocate a node in pdebug, which has an hour time limit
salloc -N1 -ppdebug

# try spack install
yogrtdir=/path/to/libyogrt/spack/install/lib
gcc -o grt grt.c -L${yogrtdir} -Wl,-rpath,${yogrtdir} -lyogrt
./grt
2147483647

# try again with system install of libyogrt
yogrtdir=/usr/lib64
gcc -o grt grt.c -L${yogrtdir} -Wl,-rpath,${yogrtdir} -lyogrt
./grt
3547
```

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by examining the existing libyogrt tests and the grt.c example described in the issue. Determine how tests are run for SLURM and LSF, then cover system, Spack, and autotools installs. Done means verifying remaining time decreases as expected for both schedulers and installation methods.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
devops, distributed-systems, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.