You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document is the single source of truth on contributing towards this codebase. Feel free to browse the [open issues](https://github.com/splunk/splunk-operator/issues) and file new ones - all feedback is welcome!
9
-
10
-
## Navigation
11
-
12
-
-[Contributing to the Project](#contributing-to-the-project)
-[Bug reports and feature requests](#bug-reports-and-feature-requests)
19
-
-[Fixing issues](#fixing-issues)
20
-
-[Pull requests](#pull-requests)
21
-
-[Maintainer Workflow for External Contributions](#maintainer-workflow-for-external-contributions)
22
-
-[Code Review](#code-review)
23
-
-[Testing](#testing)
24
-
-[Documentation](#documentation)
25
-
-[Maintainers](#maintainers)
26
-
27
-
## Prerequisites
28
-
When contributing to this repository, first discuss the issue with a [repository maintainer](#maintainers) via GitHub issue, Slack message, or email.
29
-
30
-
#### Contributor License Agreement
31
-
We only accept pull requests submitted from:
32
-
* Splunk employees
33
-
* Individuals who have signed the [Splunk Contributor License Agreement](https://www.splunk.com/en_us/form/contributions.html)
34
-
35
-
#### Code of Conduct
36
-
All contributors are expected to read our [Code of Conduct](contributing/code-of-conduct.md) and observe it in all interactions involving this project.
37
-
38
-
## Contribution Workflow
39
-
Help is always welcome! For example, documentation can always use improvement. There's always code that can be clarified, functionality that can be extended, and tests to be added to guarantee behavior. If you see something you think should be fixed, don't be afraid to own it.
40
-
41
-
#### Bug reports and feature requests
42
-
Have ideas on improvements? See something that needs work? While the community encourages everyone to contribute code, it is also appreciated when someone reports an issue. Please report any issues or bugs you find through our [issue tracker](https://github.com/splunk/splunk-operator/issues).
43
-
44
-
If you are reporting a bug, please include:
45
-
* Your operating system name and version
46
-
* Details about your local setup that might be helpful in troubleshooting (e.g. Kubernetes Version, Container Platform, Ansible version, etc.)
47
-
* Detailed steps to reproduce the bug
48
-
49
-
We'd also like to hear your feature suggestions. Feel free to submit them as issues by:
50
-
* Explaining in detail how they should work
51
-
* Keeping the scope as narrow as possible. This will make it easier to implement
52
-
53
-
#### Fixing issues
54
-
Look through our [issue tracker](https://github.com/splunk/splunk-operator/issues) to find problems to fix! Feel free to comment and tag corresponding stakeholders or full-time maintainers of this project with any questions or concerns.
55
-
56
-
#### Pull requests
57
-
A pull request informs the project's core developers about the changes you want to review and merge. Once you submit a pull request, it enters a stage of code review where you and others can discuss its potential modifications and add more commits later on.
58
-
59
-
To learn more, see [Proposing changes to your work with pull requests
60
-
](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests) in the [GitHub Help Center](https://help.github.com/).
61
-
62
-
To make a pull request against this project:
63
-
1. Fork the [splunk-operator GitHub repository](https://github.com/splunk/splunk-operator/).
64
-
1. Clone your fork and create a branch off of `develop`.
65
-
```
66
-
# Create a local copy (or clone) of the repository
# Commit the change to your repo with a log message
84
-
$ git commit -m "<helpful commit message>"
85
-
86
-
# Push the change to the remote repository
87
-
$ git push
88
-
```
89
-
1. Submit a pull request through the GitHub website using the changes from your forked codebase
90
-
91
-
#### Maintainer Workflow for External Contributions
92
-
93
-
When a pull request is submitted from a forked repository (external contributor), the CI/CD pipeline running on the fork will not have access to our internal test infrastructure. To properly test these contributions, maintainers should follow this workflow:
94
-
95
-
1. **Initial Review**: Before running any code on internal infrastructure, thoroughly review the pull request to verify it is safe to execute. Check for:
96
-
- **Security concerns**: No malicious code, credential harvesting, or unauthorized access attempts
97
-
- **Resource safety**: No code that could damage or overload internal infrastructure
98
-
- **Code quality**: Adherence to project standards and coding conventions
99
-
- **Overall approach**: Changes align with project goals and architecture
100
-
101
-
**Only proceed to the next step if you are confident the changes are safe to run on internal infrastructure.**
102
-
103
-
2. **Pull and Push to Internal Branch**: Once the initial review is satisfactory and you want to run the full test suite:
6
+
# Contributing to Splunk Operator for Kubernetes
7
+
8
+
Thanks for contributing to Splunk Operator for Kubernetes (SOK).
9
+
This guide describes how to contribute changes that are easy to review, safe to run, and aligned with this repository's workflow.
10
+
11
+
## Table of Contents
12
+
13
+
-[Quick Start](#quick-start)
14
+
-[Before You Start](#before-you-start)
15
+
-[Local Development Setup](#local-development-setup)
-`I have read the CLA Document and I hereby sign the CLA`
68
+
-`I have read the Code of Conduct and I hereby sign the COC`
69
+
70
+
You can retrigger the agreements workflow with:
71
+
72
+
-`recheck`
73
+
74
+
## Local Development Setup
75
+
76
+
Key tool versions are maintained in `.env` (for example `GO_VERSION`, `OPERATOR_SDK_VERSION`).
77
+
78
+
Useful commands:
79
+
80
+
```bash
81
+
make help
82
+
make fmt
83
+
make vet
84
+
make test
85
+
make build
86
+
```
87
+
88
+
If you modify user-facing behavior, update documentation in `docs/`.
89
+
90
+
## Contribution Workflow
91
+
92
+
### Branching
93
+
94
+
- Base branch: `develop`
95
+
- Use one short-lived branch per change
96
+
- Keep each PR focused on one logical objective
97
+
98
+
Example:
136
99
137
-
**Important Notes:**
138
-
- Always maintain clear communication with external contributors about the testing process
139
-
- The internal test branch is temporary and should be deleted after the PR is merged or closed
140
-
- This workflow ensures external contributions receive the same level of testing as internal changes
141
-
- Never merge the internal test branch directly; always merge the original PR from the fork
100
+
```bash
101
+
git checkout develop
102
+
git pull
103
+
git checkout -b your-branch-name
104
+
```
105
+
106
+
### Commits
142
107
143
-
#### Code Review
144
-
There are two aspects of code review: giving and receiving.
108
+
- Keep commits small and coherent
109
+
- Use clear commit messages
110
+
- Avoid mixing unrelated cleanup with functional changes
145
111
146
-
A PR is easy to review if you:
147
-
* Follow the project coding conventions.
148
-
* Write good commit messages, concise and descriptive.
149
-
* Break large changes into a logical series of smaller patches. Patches individually make easily understandable changes, and in aggregate, solve a broader issue.
112
+
### Push and open PR
150
113
151
-
Reviewers are highly encouraged to revisit the [Code of Conduct](contributing/code-of-conduct.md) and must go above and beyond to promote a collaborative, respectful community.
114
+
```bash
115
+
git add <files>
116
+
git commit -m "<concise and descriptive message>"
117
+
git push -u origin your-branch-name
118
+
```
152
119
153
-
When reviewing PRs from others, [The Gentle Art of Patch Review](http://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) suggests an iterative series of focuses, designed to lead new contributors to positive collaboration without inundating them initially with nuances:
154
-
* Is the idea behind the contribution sound?
155
-
* Is the contribution architected correctly?
156
-
* Is the contribution polished?
120
+
Then open a PR against `develop`.
157
121
158
-
Merge requirements for this project:
159
-
* at least 2 approvals
160
-
* a passing build from our continuous integration system.
122
+
## Testing Expectations
161
123
162
-
Any new commits to an open pull request will automatically dismiss old reviews and trigger another build.
124
+
At minimum, run for code changes:
163
125
164
-
#### Testing
165
-
Testing is the responsibility of all contributors. To run Unit Tests in Splunk Operator code, you can run below command -
126
+
```bash
127
+
make fmt vet
128
+
make test
129
+
make build
166
130
```
167
-
$ make test
131
+
132
+
For API/CRD changes:
133
+
134
+
```bash
135
+
make manifests generate
168
136
```
169
137
170
-
#### Documentation
171
-
We can always use improvements to our documentation! Anyone can contribute to these docs, whether you identify as a developer, an end user, or someone who just can’t stand seeing typos. What exactly is needed?
138
+
Integration test suites are located under `test/` and workflow-based integration jobs run in GitHub Actions.
139
+
Use targeted test runs when possible and include evidence in your PR description.
140
+
141
+
## Pull Request Expectations
142
+
143
+
A strong PR includes:
172
144
173
-
1. More complementary documentation. Have you found something unclear?
174
-
1. More examples or generic templates that others can use.
175
-
1. Blog posts, articles and such – they’re all very appreciated.
145
+
- Clear problem statement and scope
146
+
- Summary of key changes
147
+
- Test evidence (commands + outcomes)
148
+
- Related issue/Jira/support references
149
+
- Documentation updates when behavior changes
176
150
177
-
You can also edit documentation files directly in the GitHub web interface, without creating a local copy. This can be convenient for small typos or grammar fixes.
151
+
Use `.github/pull_request_template.md` as the baseline checklist.
178
152
179
-
## Maintainers
153
+
## Maintainer Workflow for External Contributions
180
154
181
-
If you need help, tag one of the active maintainers of this project in a post or comment. We'll do our best to reach out to you as quickly as we can.
155
+
PRs from forks do not have access to all internal credentials and environments.
156
+
When full internal validation is needed, maintainers should:
0 commit comments