Prepare Overlay repository for new Build process

[lornajane]

For the upcoming Overlays 1.2 release, we should prepare to be an early adopter of the new https://github.com/oai/build-infra approach - the README on that project has instructions for the changes that are made and how the release process works. We may need to expand this issue description or put together a checklist of actions needed.

[lornajane]

FYI @handrews - we're coming up to release, can we be the test subject for the new process?

[handrews]

@lornajane I think the difficulty would be that the build-infra package assumes the directory and branch layout used by OAS and Arazzo. Do you want to migrate this repo to that structure first?

[lornajane]

Yes I suggest we update to align to the other projects' structure, that's why I thought we might need a checklist

[handrews]

I think the branch migration goes something like:

• branch dev off of main
• on dev:
  • mkdir -p src/schemas/validation
  • git mv versions/1.2.0-dev.md src/overlay.md # or whatever you want to call it
  • git mv schemas/v1.2-dev/schema.yaml src/schemas/validation/schema.yaml
  • git mv schemas/v1.2-dev/readme.md src/schemas/validation/README.md
  • Edit schema.yaml and README.md with the expected placeholders for versions and dates
• on main:
  • git rm versions/1.2.0-dev.md
  • git rm schemas/v1.2-dev/schema.yaml
  • git rm schemas/v1.2-dev/readme.md
• branch v1.2-dev off of dev

But it would be good if @ralfhandl reviews this as well, as I recall that he made some tweaks to the original idea.

I don't know what needs to be done with the schema test infrastructure (@ralfhandl or @karenetheridge might know?) — The build-infra repo should be able to handle the simpler single-schema usage of Overlay (and Arazzo). It knows that the complex schema layout is an OAS-specific thing. Or there's a config option or something.

I assume some workflows need updates as well, but I'm less clear on that, and less clear on what needs to be updated vs just starting with what is in the build-infra repo as a template for new repositories.

[lornajane]

Note to self: don't forget to update contributing file!

We do have some wrapper scripts but since something always fails and script obfuscates what was happening and which bit didn't happen, I might just drop them for now and document the steps - we can automate the written process once we know it works.

[lornajane]

I think we'll also need the sync automation that the other repositories need, but anything we add manually to main (such as the contributing things) I can manually move across for now. I'll also figure out the workflows as I go along ....

[handrews]

@lornajane with the new build infrastructure, there is only one dependency to update, so it could be done manually.
We don't really need to update it every time a package updates, we only need to update it when we're going to make use of one of the updates (either because schema tests benefit from it, or because we're publishing a release or otherwise changed our build behavior).