Skip to content
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

Run CI in individual component repositories #82

Closed
oddhack opened this issue Apr 29, 2024 · 2 comments · Fixed by #85
Closed

Run CI in individual component repositories #82

oddhack opened this issue Apr 29, 2024 · 2 comments · Fixed by #85
Assignees
Labels
feature request New behavior or content process meta-issues for builds, external dependencies, etc.
Milestone

Comments

@oddhack
Copy link
Collaborator

oddhack commented Apr 29, 2024

Something we suffer from pretty frequently is a site build failure due to something minor, but hard to diagnose in a component. Vulkan-Samples seems particularly prone to this, probably because it has dozens of third-party submodules. This is a problem when I'm trying to do a spec release and want to keep the docs site current with the registry specs as I see errors in repositories I don't understand and can't easily fix myself.

I see two plausible solutions:

  • Lock component versions at particular tags or commits. This would require some banging on the build scripts in order to build the Antora sources from the right tag, and I suspect is the sort of thing that will generally be overlooked in the pressure to get more and updated content into those repositories, so the docs site will lag for those components.
  • Do an Antora build in each repository as part of CI. Not the full site build, but a truncated version which just builds that specific repository's component to check for internal consistency. This will require adding a minimal playbook to each repo and replicating the CI structure in Vulkan-Site itself.

I think the second is better, if repo owners are willing to live with it, and defer merging things to main until they pass CI. At minimum myself, @gpx1000, @SaschaWillems (whom I just added as a user to this repo so I could @-tag), and myself would need to align. A risk is that if there is some sort of meta-problem, like #81 with our UI repository, that would block CI in all repos doing a build.

@oddhack oddhack added feature request New behavior or content process meta-issues for builds, external dependencies, etc. labels Apr 29, 2024
@oddhack oddhack added this to the Needs Triage milestone Apr 29, 2024
@SaschaWillems
Copy link
Collaborator

I'm more than fine with the second solution. Very few contributors know about Antora, and as you noticed Antora builds break of this if we don't catch those problems during our review process.

So having a CI step that builds the Antora part of e.g. the samples repo and then fails if not successful would also help us in the samples review process.

Adding a minimal playbook is exactly what I do locally. I have a light-weight Antora project that has minimal playbooks for the repos I work on (Guide, Tutorial, Samples) so I can easily see if Antora builds are okay :)

@gpx1000
Copy link
Collaborator

gpx1000 commented May 2, 2024

I tend to agree I think the second path is the right one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New behavior or content process meta-issues for builds, external dependencies, etc.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants