Prevent accidental commits of generated `project` files about nmdc-schema

[eecavanna]

I don't know that Git allows for this: store files in the repo, but ignore changes to those files. 🤷

Maybe this will involve a check performed by GitHub Actions.

Or a $ make committable command that uses Git to revert the generated files to their original states.

Maybe it will involve changing how/where the files are generated.

[turbomam]

Thanks for thinking this though, @eecavanna

Here are my goals:

• all of the project/, nmdc_schema/ and examples/output files generated by make squeaky-clean all test should be included in releases. I think @pkalita-lbl thinks including examples/output/ and maybe some other generated files is excessive and I would be willing to reconsider. The examples/output/ files are nice because they show the src/data/valid/ files in their canonical forms. My release strategy has been
  1. merging pending PRs into main
  2. making and merging a new PR in which the version strings in src/schema/nmdc.yaml and pyproject.toml are updated
  3. checking out the latest main, running make squeaky-clean all test, and committing that directly into main. That could be modified if there is a better flow.
• generally speaking, PRs should not update any of those files, with one big exception: Python code in nmdc_schema/ authored by an NMDC team member. This is in contrast with autogenerated Python files in that directory, like the following. I am open to re-organizing the authored code from the generated code, but that shoud to be done in a way that doesn't complicate building or using the package.
  • nmdc.py
  • nmdc_schema_accepting_legacy_ids.py
  • nmdc_schema_merged.yaml
• it would be nice if changes to project/, authored code in nmdc_schema/ and examples/output was not reported by git status and was blocked by the .gitignore, but if that isn't possible, we can write better documentation and/or restructure nmdc_schema/
• if merging the berkeley-schema-fy24 fork into nmdc-schema will cause conflicts in project/, nmdc_schema/ or examples/output, we could make an exception an allow that, following the release flow I have documented above

PS: when @aclum's Napa re-iding squad is done, we can modify the Makefiles so that the nmdc_schema_accepting_legacy_ids* files aren't generated any more.