Skip to content
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.

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

prow: dev-release-note functionality #5843

Closed
munnerz opened this issue Dec 6, 2017 · 30 comments
Closed

prow: dev-release-note functionality #5843

munnerz opened this issue Dec 6, 2017 · 30 comments
Labels
area/jobs area/prow Issues or PRs related to prow kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. sig/release Categorizes an issue or PR as relevant to SIG Release.

Comments

@munnerz
Copy link
Member

munnerz commented Dec 6, 2017

sig-api-machinery are trying to improve the developer experience when building Kubernetes. We currently have a list of >100 PRs that do not specify release notes as they are solely developer facing changes, however this has caused many problems resulting in end users needing to look through recently merged PRs in order to work out how to fix their own code.

Ideally, there'd be some way for users to specify a 'developer' release note when writing PRs. After some discussion, @sttts suggested something along the lines of a new dev-release-note tag that is optional for all PRs (in order to not require all users to specify a dev-release-note on existing PRs).

Ideally we'd then have some kind of regex that matches directories, and enforces a dev-release-note for PRs that touch files matching the regex. It'd be possible to specify NONE just like with release-note still (for cases where it does not make sense to include a dev-release-note).

Is this something that can be considered to be included in Prow, and have sig-testing got any thoughts on how this might/should look?

/cc @sttts @nikhita @BenTheElder @fejta @spiffxp

@BenTheElder
Copy link
Member

BenTheElder commented Dec 6, 2017 via email

@munnerz
Copy link
Member Author

munnerz commented Dec 6, 2017

Sure - I didn't want to be too intrusive to the existing process is all (we end out with something that looks like this comment everywhere)

Release note:

NONE

Developer release note:

NONE

@BenTheElder
Copy link
Member

/cc @cblecker @grodrigues3 @kubernetes/sig-contributor-experience-feature-requests
/kind feature

@k8s-ci-robot k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. labels Dec 6, 2017
@cblecker
Copy link
Member

cblecker commented Dec 6, 2017

A couple questions:

  • When you say "developer" I assume you are talking about "Developers building atop the API (e.g., client libraries, CRDs)", as opposed to contributors to the k8s project directly, or "End users deploying and managing applications (application operators and developers)". Is this assumption correct?
  • If so, I also assume that these "Dev Release Notes" would need to be published? How often (same release cycle)?

@sttts
Copy link
Contributor

sttts commented Dec 6, 2017

"Developers building atop the API (e.g., client libraries, CRDs)"

This.

If so, I also assume that these "Dev Release Notes" would need to be published? How often (same release cycle)?

In every release of Kubernetes which has a matching release of our published libraries, e.g. client-go, apimachinery, etc. We would put the release into the Github release/tag markdown.

@BenTheElder
Copy link
Member

BenTheElder commented Dec 6, 2017

also FYI @cjwagner since this would touch on Tide / Prow

I think this is certainly possible, but before implementing we should have a specific proposal and loop in ContribEx, when you say enforcing do you mean not allowing merge without a value? If so we should probably just add it to all PRs and handle it the same as the existing release note process.
Edit: handle it from the infra side, obviously the labels etc wouldn't be exactly the same..

@cblecker
Copy link
Member

cblecker commented Dec 6, 2017

Based on @sttts's answers, I'd suggest this would be more a topic for @kubernetes/sig-release-feature-requests then for contribex.

I would also suggest that perhaps there is a way to flag a release note in the text as being applicable to devs (similar to action required), and use the same release note system we already have.

@k8s-ci-robot k8s-ci-robot added the sig/release Categorizes an issue or PR as relevant to SIG Release. label Dec 6, 2017
@sttts
Copy link
Contributor

sttts commented Dec 6, 2017

/cc @caesarxuchao

@caesarxuchao
Copy link
Member

@sttts
Copy link
Contributor

sttts commented Dec 6, 2017

@caesarxuchao @roycaihw awesome document. Fits perfectly here.

@BenTheElder
Copy link
Member

BenTheElder commented Dec 11, 2017

@caesarxuchao @sttts that looks pretty good to me, I think the problem is that this requires prow jobs to have GitHub API access.

Possibly we could do this the way @fejta-bot works, which is to just comment on the PR with /command foo with a token / account that has no special privileges and then have prow convert this to adding a label. The downside to this is that we wouldn't be restricting the ability to add these labels.

#5848 might be another option. /cc @cjwagner

@BenTheElder BenTheElder added area/prow Issues or PRs related to prow area/jobs labels Dec 11, 2017
@sttts
Copy link
Contributor

sttts commented Dec 12, 2017

Possibly we could do this the way @fejta-bot works

Where is the current release-note logic? Can't we re-use that code?

@BenTheElder
Copy link
Member

Where is the current release-note logic? Can't we re-use that code?

It's in prow/plugins/releasenote, but it's not a prow job and I don't think it inspects the file contents so the above doc wouldn't quite match up. It would certainly be more straight forward to do a prow plugin / extend the releasenote plugin but the sticking point would probably be needing to grep godeps.

I'm pretty sure the existing logic doesn't even inspect the file names in the PR @cjwagner .

@sttts
Copy link
Contributor

sttts commented Dec 12, 2017

I don't think it inspects the file contents

got it.

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 12, 2018
@nikhita
Copy link
Member

nikhita commented Mar 12, 2018

/remove-lifecycle stale

I'd suggest this would be more a topic for @kubernetes/sig-release-feature-requests then for contribex.

If we were to get this in, what should be the next step? Talk to sig-release and sig-contribex?

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 12, 2018
@BenTheElder
Copy link
Member

An aside: I think now something like this would be a good target for an external plugin.

@nikhita
Copy link
Member

nikhita commented Jun 7, 2018

Reviving this again:

If we were to get this in, what should be the next step? Talk to sig-release and sig-contribex?

@nikhita
Copy link
Member

nikhita commented Jun 7, 2018

I'm happy to work on the automation bits for this if proper guidelines are first agreed upon. :)

Right now, we go through all PRs created against client-go, apimachinery, etc in staging in k/k, check if the code change is relevant enough for a release note, write the release note in a spreadsheet and then convert it to markdown.

I just created the spreadsheet for release-8 for client-go. It has 201 PRs! 😱

@BenTheElder
Copy link
Member

Hi yes, talking to contribex and release about how this should work would be good. I should have commented the first time instead of +1ing 🙃

@nikhita
Copy link
Member

nikhita commented Jun 7, 2018

Hi yes, talking to contribex and release about how this should work would be good. I should have commented the first time instead of +1ing upside_down_face

👍 🙂

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 5, 2018
@nikhita
Copy link
Member

nikhita commented Sep 22, 2018

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 22, 2018
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 21, 2018
@fejta-bot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jan 20, 2019
@sttts
Copy link
Contributor

sttts commented Jan 21, 2019

/remove-lifecycle rotten

@k8s-ci-robot k8s-ci-robot removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Jan 21, 2019
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 28, 2019
@fejta-bot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 28, 2019
@fejta-bot
Copy link

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

@k8s-ci-robot
Copy link
Contributor

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/jobs area/prow Issues or PRs related to prow kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. sig/release Categorizes an issue or PR as relevant to SIG Release.
Projects
None yet
Development

No branches or pull requests

8 participants