-
Notifications
You must be signed in to change notification settings - Fork 34
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 documentation CI weekly #101
Comments
Instead of looping trying to find a free loop device, use `losetup -f` to find the first unused. Fixes: kata-containers#101. Signed-off-by: Salvador Fuentes <salvador.fuentes@intel.com>
This would also help identify broken URLs faster. |
@jodh-intel @chavafg - ack, this is one of a number of things we should run on a regular cadence. I think that is actually pretty easy/trivial to set up in Jenkins - but, the hard part in my mind is how/where do we report the results? Options off the top of my head are:
I'd really like to get the version check and CVE check tools onto a regular cadence run with email updates - so I'm all ears to solutions here. |
It may not be hip'n'all, but... +1 for email 😄 |
Closing this issue as related with kata 1.x |
As explained kata-containers/documentation#346 (comment), every time a PR is raised on the documentation repo, we run all the install tests by "executing" all the install docs. That's helpful, but if nobody raises any doc PRs, we're not actively testing the install docs (bad).
Since the distro repos changes constantly, even though kata was installable yesterday for all repos, it may not install tomorrow if, say, a new version of docker lands in Ubuntu/Fedora which somehow breaks us.
We should run the documentation repos CI weekly so we get a regular heartbeat to assure us Kata is still installable.
Notes:
This job should be for all architectures that we OBS build packages for
Sadly, that's only
x86_64
currently. See:This job would only currently apply to installing Kata from
master
- I don't think we're quite at the point where we can handle also testing the stable branches. This is frustrating but we haven't yet decided on how to handle stable install docs. The obvious solution is to fork the docs repo when we create a new stable release, tweak (automatically) the install docs, then re-test those install docs. See:The text was updated successfully, but these errors were encountered: