hashicorp / nomad-openapi

OpenAPI specification and related artifacts for HashiCorp Nomad

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

feature: Add script to split generated clients to their own commit and update docs

DerekStrickland opened this issue · comments

  • Split client directory changes into a separate commit automatically
  • Investigate if it could be a commit hook
  • Investigate if it should create one commit per language

I don't think think can be implemented as a pre-commit hook as it operates on staged items...unless the workflow happens like:

  1. git reset
  2. add client dir to add/stash, commit AND push with a templated commit message
  3. finally will add/stash the remaining code and commit

We can loop step no. 2 for each of the clients if we want each client to be its own separate commit. This can be done thru some sort of config file with folder names and a templated commit message:

example:

folders:
  - clients
    - go
    - java
    - javascript
    - python
    - ruby
    - rust
    - typescript
commit_message: "commiting [folders.clients]"

I'm not following the stashed part. I don't see anything about stash in the docs I am looking at. Is that part of your workflow or something git is doing that I'm not aware of?

I was imagining it could do something like

git commit -m "OpenAPI generator client updates" ./clients 

I'm guessing there's a fair bit of nuance here though. 🤔

Ooops! I meant staged, not stashed.

Yeah I think I get it now. I suppose you could get clever and write a post commit hook but that feels dangerous 🤔

Maybe the solutions is to have the make v1 command just commit the clients folder then, and if the author runs it multiple times, it's on them or the reviewer to squash those? It could move things forward...

I've been playing with some stuff and probably at the next meeting I can show what I have and we can discuss how best to approach this. I don't think there's any ideal solution -- there will be some compromise either way, it's just a question of which one we think is the easiest to implement.

Sounds good! Looking forward to it.