kubernetes/minikube

add detailed info about what each integration test is doing to the site

Open

#11,571 opened on Jun 3, 2021

View on GitHub
 (16 comments) (0 reactions) (1 assignee)Go (31,799 stars) (5,222 forks)batch import
area/testinggood first issuekind/documentationlifecycle/frozenpriority/backlog

Description

currently our make generate-docs creates this page

https://minikube.sigs.k8s.io/docs/contrib/tests/

which generates the site based on the Comments on the Test and validate the func,

I would like these descriptions to exaclty say what it is doing instead of a general text 

validateBuildImage 
makes sures that minikube image build works as expected

it should say

validateBuildImage makes sures that `minikube image build` works as expected
 builds an image using `minikube image build` and 
 the Dockerfile located in test/integration/testdata/build/Dockerfile 
 which adds a relative file into a busybox container
 and then ensures the image was build using image inspect inside minikbue 
 special case :
 in case of contained it starts the buildkit inside minikube
 currently skipped on None Driver and Github Actions on MacOs,

Contributor guide

Tech stack
godocker
Domain
documentation
Issue type
documentation
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
blocked
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Go programmingminikube integration test structureDocker basics
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
60
Research direction
Examine the existing test functions in the test/integration/ directory, such as validateBuildImage, and update their documentation comments to include detailed information about what each test does, including build steps, special cases (e.g., containerd), and skipped conditions. Ensure the comments follow the format shown in the issue example. Review any previous comments or maintainer guidance in the issue for additional context.