MinIO can be accessed via port {{ .Values.service.port }} on an external IP address. Get the service external IP address by:
kubectl get svc --namespace {{ .Release.Namespace }} -l app={{ template "minio.fullname" . }}

Note that the public IP may take a couple of minutes to be available.

You can now access MinIO server on http://<External-IP>:9000. Follow the below steps to connect to MinIO server with mc client:

participant dep as Dep with yield
participant operation as Path Operation
participant tasks as Background tasks

    Note over client,tasks: Can raise exception for dependency, handled after response is sent
    Note over client,operation: Can raise HTTPException and can change the response
    client ->> dep: Start request
    Note over dep: Run code up to yield
    opt raise
        dep -->> handler: Raise HTTPException

        with:
          # excluded:
          # - notes.md and notes-templates.md - because they are a part of user guide
          # - Kotlin's Module.md - because it's a part of the Kotlin DSL docs
          args: >
            --no-progress --offline '**/*.md' --include-fragments
            --exclude-path 'platforms/documentation/docs/src/docs/release/notes.md'

        sampleSampleDoc = new File(projectDir, "build/working/samples/docs/sample_sample.adoc")

        new File(projectDir,"build/working/release-notes").mkdirs()
        releaseNotes = new File(projectDir, "build/working/release-notes/raw.html")

        linkErrors = new File(projectDir, "build/reports/dead-internal-links.txt")

        new File(projectDir, "gradle.properties") << """

You could put your XML content in a string, put that in a `Response`, and return it:

{* ../../docs_src/response_directly/tutorial002_py39.py hl[1,18] *}

## Notes { #notes }

When you return a `Response` directly its data is not validated, converted (serialized), or documented automatically.

## Available versions { #available-versions }

You can see the available versions (e.g. to check what is the current latest) in the [Release Notes](../release-notes.md){.internal-link target=_blank}.

## About versions { #about-versions }

Following the Semantic Versioning conventions, any version below `1.0.0` could potentially add breaking changes.

## Versiones disponibles { #available-versions }

Puedes ver las versiones disponibles (por ejemplo, para revisar cuál es la más reciente) en las [Release Notes](../release-notes.md){.internal-link target=_blank}.

## Sobre las versiones { #about-versions }

    stage: Stage,
) : OsAwareBaseGradleBuildType(os = Os.LINUX, stage = stage, init = {
        id(buildTypeId(model))
        name = "Sanity Check"
        description = "Static code analysis, checkstyle, release notes verification, etc."

        features {
            publishBuildStatusToGithub(model)
        }

        applyDefaults(
            model,
            this,
            "sanityCheck",

So, having a nice PR title will not only look nice in GitHub, but also in the release notes. 📝

## Add Labels to PRs

The same GitHub Action <a href="https://github.com/tiangolo/latest-changes" class="external-link" target="_blank">latest-changes</a> uses one label in the PR to decide the section in the release notes to put this PR in.

### `///` admonitions

1) Keep the admonition keyword in English (do not translate `note`, `tip`, etc.).
2) If a title is present, prefer these canonical titles:

- `/// note | 참고`
- `/// tip | 팁`
- `/// warning | 경고`
- `/// info | 정보`
- `/// danger | 위험`
- `/// note Technical Details | 기술 세부사항`
- `/// check | 확인`
Notes: