Add a basic JSON validation CI action

[peternewman]

No description provided.

[ssilverman]

Could you combine the commits into one?

[peternewman]

I could, or you could just use the Squash and Merge option, which is probably less effort all round:
https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-pull-request-commits

You might need to enable it first:
https://docs.github.com/en/github/administering-a-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests

[peternewman]

Is the Squash and Merge option acceptable @ssilverman or do you want me to have a go from my end?

[ssilverman]

I'm familiar with squash merges, I just wanted to give you an opportunity to create your own commit message. If you don't want to, I'll just create a commit and give you credit in the comments.

[peternewman]

I believe if you do them from GitHub then I think it takes the Pull Request message as the message (or something equally clever/sensible) and deals with the credit too, I think we both get credited or it shows me as the author in collaboration with you or vice versa so it still properly shows my authorship, not just as a comment in the commit message.

Basically I'd rather you just did that, and it's less effort all round I believe.

I'll avoid writing the same thing on the other PRs...

[ssilverman]

That's true, but I think it also puts all the temporary commits into the message too. This is a single-file one-change commit that's in 4 5 6 commits. Could you combine them into one?

[ssilverman]

Here's the workflow that I'd like for this repo (I should really put this into a contributor's guide):

1. I'm using a rebase approach for linear history. (I'm used to working on very large codebases with lots of people, and so my habits are from that.)
2. Combine multi-commit changes that really are only one change into a single commit.
3. In the PRs, use a single commit per "thing", and put unrelated changes into different PRs.
4. Force push as necessary into your own branch to do the commit combining, so that the rebase-merge into the main branch keeps the above points.

[peternewman]

That's true, but I think it also puts all the temporary commits into the message too. This is a single-file one-change commit that's in 4 5 6 commits. Could you combine them into one?

I've just tried a test squash and merge, my PR looked like this:
peternewman#8

The resulting squash and merge commit looks like this:
peternewman@e72a09a

As you'll see you can sub/copy edit the commit message to your hearts content to fit your preferred workflow.

Here's the workflow that I'd like for this repo (I should really put this into a contributor's guide):

Yes you should, if you use a magic name, GitHub does lots of clever stuff when it shows it to people (although I think frustratingly only after you've made an edit and open a PR...):
https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

1. I'm using a rebase approach for linear history. (I'm used to working on very large codebases with lots of people, and so my habits are from that.)

I'd say the OLA codebase is pretty big, and we've got away with it, I don't really know how it compares to what you've worked on, anyway it's your repo so you're welcome to run it as you want.

2. Combine multi-commit changes that really are only one change into a single commit.

I think squash will do that. I've done 95% of the edits to this repo/open PRs solely on the GitHub website, rather than downloading and installing all the random tools, which unfortunately translates to a lot of commits, but does mean a very low barrier to entry.

3. In the PRs, use a single commit per "thing", and put unrelated changes into different PRs.

Makes sense, you may want to clarify if things like my typo fix which is independent of adding the action are unrelated or not, or how literally you want to take that if I see a typo in a file I'm editing...

4. Force push as necessary into your own branch to do the commit combining, so that the rebase-merge into the main branch keeps the above points.

I'm not certain, but I think one of the GitHub workflows will cover that for you.

[ssilverman]

What do you mean by "JSONs Alternative"?

[peternewman]

Just that it was one of a number of ways of doing the validation. My first was https://github.com/peternewman/rdm-schema/tree/validation which still seems to fail ( https://github.com/peternewman/rdm-schema/runs/3279250852?check_suite_focus=true ), I think possibly as the validator is older than the schema you're now using.

Given the various online and CLI validators seem to catch different things, running a suite of them probably makes sense, but maybe I should name them based on which tool is doing the validation for each run.

[peternewman]

Closing this in favour of #8