linting + CI

[kne42]

adds linting (including pre-commit) and workflows for running linting and tests:

• pre-commit
• frontend tests
• frontend linting
• frontend type-check
• backend linting
• backend code-style

[codecov]

Codecov Report

Merging #96 (217358b) into main (e82082c) will increase coverage by 0.31%.
Report is 2 commits behind head on main.
The diff coverage is 64.51%.

❗ Current head 217358b differs from pull request most recent head dc34d90. Consider uploading reports for the commit dc34d90 to get more accurate results

@@            Coverage Diff             @@
##             main      #96      +/-   ##
==========================================
+ Coverage   78.52%   78.84%   +0.31%     
==========================================
  Files           7        7              
  Lines         503      501       -2     
==========================================
  Hits          395      395              
+ Misses        108      106       -2     

Flag	Coverage Δ
unittests	78.84% <64.51%> (+0.31%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...oet_data_portal/src/cryoet_data_portal/__init__.py	81.81% <100.00%> (ø)
...yoet_data_portal/src/cryoet_data_portal/_client.py	93.33% <100.00%> (-0.42%)	⬇️
client/python/cryoet_data_portal/tests/conftest.py	100.00% <ø> (ø)
...et_data_portal/src/cryoet_data_portal/_gql_base.py	79.33% <66.66%> (ø)
...yoet_data_portal/src/cryoet_data_portal/_models.py	88.79% <90.00%> (ø)
..._data_portal/src/cryoet_data_portal/_file_tools.py	25.00% <30.76%> (+3.33%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[manasaV3]

I think this might be good to retain, as the default line limit of 80 is quite short.

[kne42]

i can revert this if you desire

[manasaV3]

Not a blocker: Yes, please, if it isn't too much trouble.

[manasaV3]

It looks like this might be more than linting changes. Pulling in the changes from the main might help fix that.

[codemonkey800]

looks like some of the keys are sorted differently 🤔 I wonder if prettier or eslint did this

[codemonkey800]

overall lgtm! left a few comments 🦙

[codemonkey800]

looks like some of the keys are sorted differently 🤔 I wonder if prettier or eslint did this

[codemonkey800]

could we leverage the pnpm cache here? there's an example in the action README: https://github.com/pnpm/action-setup#use-cache-to-reduce-installation-time

jobs:
  tests:
    steps:
      - uses: pnpm/action-setup@v2
        name: Install pnpm
        with:
          version: 8.9.0
          run_install: false

      - name: Get pnpm store directory
        shell: bash
        run: |
          echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV

      - uses: actions/cache@v3
        name: Setup pnpm cache
        with:
          path: ${{ env.STORE_PATH }}
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
          restore-keys: |
            ${{ runner.os }}-pnpm-store-

      - name: Install dependencies
        run: pnpm install

[codemonkey800]

can you verify that this doesn't install anything with npm install? I'm looking at the code for this and it looks like it's using language: node which does setup an environment using npm install

[kne42]

this does use npm install I would assume. we can circumvent this by deleting it and letting the pnpm lint command run it instead

[manasaV3]

Nit: Do we need this?

[kne42]

technically not, no

[manasaV3]

Not a blocker: We could remove it.

[manasaV3]

Not a blocker: Yes, please, if it isn't too much trouble.

[kne42]

the workflow is failing for reasons i cannot reproduce locally... id rather just merge it in now and maybe we can fix it later since it's mainly meant as a warning