-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we-organize our GitHub pages to a directory on main? #3717
Comments
I totally agree with this one. This might be a personal preference but I usually find it confusing when each branch is a different project completely. I can start with this one after this is closed #1823 |
Note that the current build process seems spread across both Also, there are infrastructure bits under the curren top-level directory on |
We should consider having a dedicated repo for spec.openapis.org? As we have now moved to a multi-specification project (and likely more coming - Overlays), nesting the website housing the specs under one of the specification repos is a little confusing. Each separate specification repo that wants to publish can issue PRs to the repo housing the HTML versions and other information relevant to spec.openapis.org. We could then have the same process in place for both |
@frankkilcommins Should each spec has its own domain maybe? For example, |
@Bellangelo We want a unified brand across the different specs, so I think we'll want to stick with spec.openapis.org. |
@handrews Fair enough. I see that @darrelmiller invited me to the organization, so now I have access to create a repo. Should I create a |
@Bellangelo I was surprised about repository creation privileges but it looks like a recent change that GitHub made, giving members more abilities. Let's make sure @darrelmiller or another admin is OK with the separate-repository choice. There might need to be a bit of work to figure out how the publishing of specs and schemas changes. Not so much the technical logistics (which I'm sure you can sort out) but the policy side of things. |
We are generally in favour. But we will need some process, governance and maintenance setup to enable this change. A good discussion in TDC, but we are not ready to make the change immediately. |
Splitting this out from #3766, to which it is still somewhat related as we should consider the impact on how many PRs to how many different branches are required for a change that spans the spec and the registries.
Originally, gh-pages sites needed to be on a
gh-pages
branch that (as ours does) typically has a completely different layout thanmain
. That is no longer required, and it is much more common to deploy from a directory onmain
. Or at least from a directory on a branch that is no more different frommain
than any other working branch.The text was updated successfully, but these errors were encountered: