GEOS-ESM / GEOS-ESM/CI-workflows
Workflow for checking pinned hashes in existing jedi bundle on discover
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 1
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
@jardizzo @ashiklom @Dooruk
I have a pinned version JEDI bundle in advda here: /discover/nobackup/projects/gmao/advda/pinned_jedi_bundle. This is the JEDI bundle that Swell points to if a user wants to use an existing pinned JEDI build (https://github.com/GEOS-ESM/swell/pull/433). The JEDI repositories in this bundle are currently pinned for August 31 as @Dooruk recommends.
I would like to make a test that uses Swell's check_hashes tool to check whether the hashes in /discover/nobackup/projects/gmao/advda/pinned_jedi_bundle correspond to the hashes tracked in Swell (https://github.com/GEOS-ESM/swell/blob/feature/pinned_versions_support/src/swell/utilities/pinned_versions/pinned_versions.yaml). This way, we can be sure that these hashes match during Swell PRs.
Let me know your thoughts on this.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with Swell's check_hashes tool and the pinned_versions.yaml file on the feature/pinned_versions_support branch. Compare its tracked hashes with the repositories in /discover/nobackup/projects/gmao/advda/pinned_jedi_bundle, then inspect the repository's existing CI workflow files. Done means a workflow test detects mismatches during Swell pull requests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100