Skip to content

Conversation

nerdeveloper
Copy link
Contributor

Summary

  • Adds documentation on creating custom markers for unsupported file extensions
  • Shows how to use Kubebuilder as a library for external plugins
  • Includes examples for Rust, Java, Python, and template files

Related

Test Plan

  • Documentation builds correctly
  • Code examples tested and compile without errors
  • Added to SUMMARY.md table of contents

@k8s-ci-robot k8s-ci-robot added the do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. label Sep 22, 2025
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: nerdeveloper
Once this PR has been reviewed and has the lgtm label, please assign camilamacedo86 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Sep 22, 2025
@k8s-ci-robot
Copy link
Contributor

Hi @nerdeveloper. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@nerdeveloper nerdeveloper force-pushed the docs/custom-markers-issue-4829 branch from ddb8cdb to 161acff Compare September 22, 2025 21:56
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. label Sep 22, 2025
- You're building an **external plugin** for a language not natively supported by Kubebuilder
- You want to scaffold files with custom extensions (`.rs`, `.java`, `.tpl`, `.py`, etc.)
- Your file extensions aren't (and shouldn't be) part of the core `commentsByExt` map
- You need to maintain scaffolding markers in non-Go files
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the documentation could be How to create Custom Markers.
For those who use Kubebuilder as a library, it would be possible to create their own custom markers, regardless of whether it is for an extension valid or not for Golang projects.

So, it would not only be valid for external references

builder.WriteString(":")
}
return builder.String()
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you let me know if you tested this example?
Can it work without any change in the code at this moment?
Is the code covered with tests to ensure that this example would be possible?

}
```

## Complete Example: Rust Plugin with Custom Markers
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need all those examples?
Could we not have only 1 example?
How could we simplify the doc and its maintainability?
Just to share what is required

Comment on lines 295 to 307
## Best Practices

1. **Use Clear Prefixes**: Choose a unique prefix for your plugin to avoid conflicts (e.g., `+rust:scaffold:`, `+java:scaffold:`)

2. **Handle Comments Correctly**: Different languages have different comment syntax. Make sure to map the correct comment style for each file extension.

3. **Error Handling**: Always validate file extensions and return clear error messages when unsupported files are encountered.

4. **Maintain Compatibility**: When possible, follow the same patterns as Kubebuilder's core marker system to maintain consistency.

5. **Document Your Markers**: Clearly document what markers your plugin supports and where they should be placed.

6. **Testing**: Test your marker implementation with various file types and edge cases.
Copy link
Member

@camilamacedo86 camilamacedo86 Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Best Practices is something subjective, I think it's better to avoid this term.

}
```

## Conclusion
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please review the other documentation we have?
We do not use a conclusion. We should always follow the same layout and standards.

@nerdeveloper
Copy link
Contributor Author

Hi @camilamacedo86,

Thank you for the review feedback! I've updated the documentation to address your comments:

✅ Changed title to "Creating Custom Markers" (broader scope, not just for unsupported extensions)
✅ Simplified to only ONE example (Rust) instead of multiple examples
✅ Removed "Best Practices" section (subjective term)
✅ Removed "Conclusion" section (to match other docs)
✅ Made the documentation more concise and maintainable

Regarding testing: I performed minimal testing of the marker generation logic by creating a standalone Go program that tests the core marker creation code. The test confirms:

  • The code compiles without errors
  • Markers are generated with correct comment syntax for different file types (e.g., // +rust:scaffold:imports for Rust, # +python:scaffold:functions for Python)
  • The marker format is correct

However, I have NOT tested the complete integration with external plugins end-to-end (the full example with templates and plugin integration).

Question: What would you prefer for this documentation?

  1. Keep the current example as a pattern/reference (with a note that it's not fully integration-tested)
  2. Simplify further to only show the minimal testable code (just the marker creation)
  3. Add a working example to an external test repository and link to it

Please let me know your preference, and I'll update accordingly!

Shows how to use Kubebuilder as a library to create custom marker support
for external plugins with non-Go file extensions like .rs, .java, .py
@nerdeveloper nerdeveloper force-pushed the docs/custom-markers-issue-4829 branch from 161acff to 51faf4e Compare September 27, 2025 10:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add docs: how to create custom markers for unsupported file extensions
3 participants