Skip to content

update retrieving non-empty legacy records #29

update retrieving non-empty legacy records

update retrieving non-empty legacy records #29

Workflow file for this run

# Based on
# https://github.com/pantsbuild/example-python/blob/main/.github/workflows/pants.yaml
name: Pants Lint and Test
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
permissions:
contents: read
jobs:
build:
name: Pants Lint and Test
runs-on: ubuntu-latest
strategy:
matrix:
python-version: [3.11]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python-version }}
- uses: pantsbuild/actions/init-pants@v8
# This action bootstraps pants and manages 2-3 GHA caches.
# See: github.com/pantsbuild/actions/tree/main/init-pants/
with:
# v0 makes it easy to bust the cache if needed
# just increase the integer to start with a fresh cache
gha-cache-key: v0
# The Python backend uses named_caches for Pip/PEX state,
# so it is appropriate to invalidate on lockfile changes.
named-caches-hash: ${{ hashFiles('python-default.lock') }}
# If you're not using a fine-grained remote caching service (see https://www.pantsbuild.org/docs/remote-caching),
# then you may also want to preserve the local Pants cache (lmdb_store). However this must invalidate for
# changes to any file that can affect the build, so may not be practical in larger repos.
# A remote cache service integrates with Pants's fine-grained invalidation and avoids these problems.
cache-lmdb-store: 'true' # defaults to 'false'
# Note that named_caches and lmdb_store falls back to partial restore keys which
# may give a useful partial result that will save time over completely clean state,
# but will cause the cache entry to grow without bound over time.
# See https://www.pantsbuild.org/2.21/docs/using-pants/using-pants-in-ci for tips on how to periodically clean it up.
# Alternatively you change gha-cache-key to ignore old caches.
- name: Lint
run: |
pants lint nacc_form_validator::
- name: Test
run: |
pants test ::