Skip to content

Add Issue and PR templates to the project #591

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Oct 17, 2018
Merged

Add Issue and PR templates to the project #591

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3fe9955
.github: Add ISSUE_TEMPLATE directory
lilic Oct 10, 2018
27f06dd
.github: Add default issue template file
lilic Oct 10, 2018
f225b9b
.github: Add PR template
lilic Oct 10, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .github/ISSUE_TEMPLATE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
<!---
Thanks for filing an issue! Before you submit, please read the following:

Check the other issue templates if you are trying to submit a bug report, feature request, or question. Search open/closed issues before submitting since someone might have asked the same thing before!
-->
42 changes: 42 additions & 0 deletions .github/ISSUE_TEMPLATE/Bug_report.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
---
me: Bug Report
about: If things aren't working as expected.

---

## Bug Report

<!--
Thanks for filing an issue! Before hitting the button, please answer these questions.

Fill in as much of the template below as you can. If you leave out information, we can't help you as well.
-->

**What did you do?**
A clear and concise description of the steps you took (or insert a code snippet).

**What did you expect to see?**
A clear and concise description of what you expected to happen (or insert a code snippet).

**What did you see instead? Under which circumstances?**
A clear and concise description of what you expected to happen (or insert a code snippet).


**Environment**
* operator-sdk version:
Copy link
Member

Choose a reason for hiding this comment

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

We may need to have two version here (maybe?) 1. is the binary's version and 2. the version from Gopkg.Toml.

Copy link
Member

Choose a reason for hiding this comment

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

Gopkg.toml exists only for go type operators, right? Might need to clarify that that version only applies to go operators.

Copy link
Member

Choose a reason for hiding this comment

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

There could also be a potential mismatch of the version from the operator-sdk binary and the base image for the ansible operator that a user is using? Don't know how to capture that though.

Copy link
Contributor

Choose a reason for hiding this comment

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

@shawn-hurley The ansible-operator logs should show the version of the vendored sdk.

INFO[0000] Go Version: go1.10.3
INFO[0000] Go OS/Arch: linux/amd64
INFO[0000] operator-sdk Version: 0.0.6+git
INFO[0000] Starting to serve on 127.0.0.1:8888

We could ask them to check the Gopkg.toml for a Go type operator. And the logs of their operator for an ansible type operator to check the version of the sdk. Assuming they can run the operator.


Insert operator-sdk release or Git SHA here. If you have paste the Gopkg.lock operator-sdk information here.

* Kubernetes version information:

Insert output of `kubectl version` here

* Kubernetes cluster kind:

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 we should add a field about using ansible/go/helm. Don't have a good idea on wording though. Maybe Are you writing your operator in ansible, go, or helm?.

* Are you writing your operator in ansible or go?

**Possible Solution**
<!--- Only if you have suggestions on a fix for the bug -->

**Additional context**
Add any other context about the problem here.
14 changes: 14 additions & 0 deletions .github/ISSUE_TEMPLATE/Feature_request.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
---
me: Feature Request
about: Suggest a feature

---

## Feature Request

**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Example: "I have an issue when [...]"

**Describe the solution you'd like**
A clear and concise description of what you want to happen. Add any considered drawbacks.

44 changes: 44 additions & 0 deletions .github/ISSUE_TEMPLATE/Question.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
---
me: Question
about: Any support questions you might have.

---
<!--
Thanks for filing an issue! Before hitting the button, please answer these questions.

Fill in as much of the template below as you can. If you leave out information, we can't help you as well.

We will try our best to answer the question, but we also have a mailing list and slack channel for any other questions.
-->

## Type of question

**Are you asking about community best practices, how to implement a specific feature, or about general context and help around the operator-sdk?**


## Question

**What did you do?**
A clear and concise description of the steps you took (or insert a code snippet).

**What did you expect to see?**
A clear and concise description of what you expected to happen (or insert a code snippet).

**What did you see instead? Under which circumstances?**
A clear and concise description of what you expected to happen (or insert a code snippet).


**Environment**
* operator-sdk version:

insert release or Git SHA here

* Kubernetes version information:

insert output of `kubectl version` here

* Kubernetes cluster kind:

**Additional context**
Add any other context about the question here.

19 changes: 19 additions & 0 deletions .github/PULL_REQUEST_TEMPLATE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
<!--

Before making a PR, please read our contributing guidelines https://github.com/operator-framework/operator-sdk/blob/master/CONTRIBUTING.MD
Copy link
Member

Choose a reason for hiding this comment

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

Should we ask submitters to make sure their branches are rebased to the latest revision of the destination branch before submitting?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would say yes. Especially given that we vendor the contributor's branch as the source in our e2e test.

If their branch is significantly behind the master there can be conflicts.

Copy link
Contributor

@AlexNPavel AlexNPavel Oct 10, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

Yeah, that would be useful considering that the tests tend to fail a lot if they are not recently rebased simply due to the way we have to handle some of our tests due to dep.


Note: Make sure your branch is rebased to the latest upstream master.

--!>

**Description of the change:**


**Motivation for the change:**

<!--

Note: If this PR is fixing an issue make sure to add a note saying:
Closes #<ISSUE_NUMBER>

--!>