public_git
/
kubernetes-operator
mirror of https://github.com/jenkinsci/kubernetes-operator.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Merge pull request #492 from jenkinsci/contribiute-guide 

Update docs and minor improvements
This commit is contained in:
Bartek Antoniak 2021-01-22 16:16:28 +01:00 committed by GitHub
parent aa45c79c56 e6e00af4d9
commit 9713375a37
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 109 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
.github/ISSUE_TEMPLATE/bug_report.md vendored Normal file
View File

@ -0,0 +1,22 @@
---
name: "🐛 Bug report"
about: Create a report to help us improve
title: ''
labels: 'bug'
projects: ''
assignees: ''
---
**Describe the bug**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior.
**Additional information**
Kubernetes version:
Jenkins Operator version:
Add error logs about the problem here (operator logs and Kubernetes events).

17
.github/ISSUE_TEMPLATE/feature_request.md vendored Normal file
View File

@ -0,0 +1,17 @@
---
name: "🚀 Feature request"
about: Suggest an idea for this project
title: ''
labels: 'enhancement'
projects: ''
assignees: ''
---
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
**Additional context**
Add any other context about the feature request here e.g. external links or diagrams, etc.

27
.github/issue_template.md vendored
View File

@ -1,27 +0,0 @@
# Expected Behavior
# Actual Behavior
# Steps to Reproduce the Problem
1.
2.
3.
# Additional Info
- Kubernetes version:
**Output of `kubectl version`:**
```
(paste your output here)
```
- Jenkins Operator version:
```
(paste your output here)
```
<!-- Any other additional information -->

63
CONTRIBUTING.md
View File

@ -1,46 +1,43 @@
# Contributing
# Contribution Model
:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
The following is a set of guidelines for contributing to the Jenkins Operator. These are mostly guidelines, not rules.
Use your best judgment, and feel free to propose changes to this document in a pull request.
In this project we appreciate any kind of contributions: code, documentation, design, etc.
Any contribution counts, and the size does not matter!
## Newcomers
If you are a newcomer contributor and have any questions, please do not hesitate to ask in the `#jenkins-operator` [Slack](https://virtuslab-oss.slack.com) Channel.
#### Table Of Contents
[Code of Conduct](#code-of-conduct)
Thanks for taking the time to contribute!
## Code of Conduct
This project and everyone participating in it is governed by the [Atom Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code.
## Commit Messages
## We Develop with GitHub
We use GitHub to host code, to track issues and feature requests, as well as accept pull requests.
All commit messages should follow
[these best practices](https://chris.beams.io/posts/git-commit/), specifically:
## We Use GitHub Flow, So All Code Changes Happen Through Pull Requests
Pull requests are the best way to propose changes to the codebase (we use GitHub Flow). We actively welcome your pull requests:
- Start with a subject line
- Contain a body that explains _why_ you're making the change you're making
- Reference an issue number one exists, closing it if applicable (with text such
as
["Fixes #245" or "Closes #111"](https://help.github.com/articles/closing-issues-using-keywords/))
- Create feature requests and discuss the scope.
- Fork the repo and create your branch from master.
- If you’ve added code that should be tested, add tests.
- If you’ve changed APIs or design, update the documentation.
- Create a draft pull request (not yet ready for review, triggers CI build).
- Ensure the e2e tests pass (wait for GitHub status checks).
- Mark that pull request as ready for review.
Not sure what to put? Try to Include:
## Quality Standards
It is important to keep the quality bar high and ensure all of us follow best practices and security, so the code is solid and can be reused by other people. Below you can find some quality standards.
- What is the problem being solved?
- Why is this the best approach?
- What other approaches did you consider?
- What side effects will this approach have?
- What future work remains to be done?
### General Contribution
## Coding standards
- Break down your pull request into smaller pieces, less code is easier to review. Most of PRs should fall under 200 lines of code changes unless specifically justified otherwise.
- Add descriptive comments and labels to pull requests and issues.
- Ensure end to end tests are passing.
- commit message should follow [these best practices](https://chris.beams.io/posts/git-commit/), specifically: start with a subject line and reference an issue number e.g. ["Fixes #245" or "Closes #111"](https://help.github.com/articles/closing-issues-using-keywords/)
### Go
### Large Architectural Changes
In case of large change which requires significant engineering effort and introduces side effects, we suggest writing a design proposal document first.
- [Go code review comments](https://github.com/golang/go/wiki/CodeReviewComments)
Design proposal is simply a document that states what you propose to do including:
- Problem statement
- Description of potential solution
- Side effects
- Breaking changes
Keep in mind that a proposal is not a pitch, it needs to be technical.

40
ROADMAP.md Normal file
View File

@ -0,0 +1,40 @@
# Jenkins Operator Roadmap
This document outlines the vision and technical roadmap for [jenkinsci/kubernetes-operator](https://github.com/jenkinsci/kubernetes-operator) project.
## Project Vision
With Jenkins Operator project we want to enable our community to run Jenkins in cloud-native environments like Kubernetes, OpenShift and others. Also, support most of the public cloud providers (AWS, Azure, GCP) in terms of additional capabilities like backups, observability and cloud security.
With declarative configuration and full lifecycle management based on [Operator Framework](https://operatorframework.io/) this can become the de facto standard for running Jenkins on top of Kubernetes.
Now, we have a dedicated team which can bring more engineering effort to the project.
## Technical Roadmap
- Upgrade Operator SDK [#494](https://github.com/jenkinsci/kubernetes-operator/issues/494)
- https://github.com/operator-framework/operator-sdk/releases/tag/v1.3.0
- Modularise codebase and define areas of responsibility (AWS, Azure, OpenShift)
- Break down Jenkins Custom Resource into smaller parts, support multiple Custom Resource Definitions [#495](https://github.com/jenkinsci/kubernetes-operator/issues/495)
- Introduce more granular schema for configuring Jenkins
- Introduce independent reconciliation controllers
- Refactor e2e tests to support testing individual reconciliation controller
- Improve contribution process and establish governance model [#496](https://github.com/jenkinsci/kubernetes-operator/issues/496)
- Improve CONTRIBUTING.md
- Introduce architecture decision proposals process
- Introduce governance model
- Migrate Jenkins instance from Pod to Deployment [#497](https://github.com/jenkinsci/kubernetes-operator/issues/497)
- Unblock easier integration with 3rd party systems e.g. sidecars injection
- Reference Architecture - Jenkins on Kubernetes
- Bridge the gap between Jenkins and Kubernetes
- https://www.jenkins.io/blog/2020/12/04/gsod-project-report/
- Pay technical debt
- Review existing issues on GitHub and prioritise them
- Introduce project board to track milestones
- Fix existing bugs
## Have a Question?
In case of further question feel free to create an issue or contact us directly.