Proposal - Introducing Global Probot configuration for Release Drafter and other tools

[Oleg Nenashev]

Hi all,

Just another GitHub infrastructure thread is here. There is a number of components which started using Release Drafter to automate management of releases notes. Basically, this tool generates changelog drafts using pull request metadata (commit headers, links, etc.). It is one of examples of many Probot-based GitHub applications which could help plugin maintainers and improve the contributor experience within the organization.

Release Drafter usage examples:

• Configuration As Code Plugin
• BlueOcean Plugin
  
• Slack Plugin
• BitBucket Branch Source Plugin
  
• Jenkinsfile Runner

All components use pretty similar configuration files and labeling strategies. For example, here is a Jenkinsfile Runner configuration file. You may see that this file defines labels, replacement logic for Jenkins JIRA and CVE references, etc. Copy-paste across repositories is problematic.Good news is that we could define configs on the org-wide basis.

Release Drafter is based on the Probot framework for GitHub apps. Probot allows managing application configs on the org-level by introducing a new system config repository (documentation). Configurations can be then overridden by repositories if needed.

What do I propose?

1. Create a Probot global configuration repository
2. Add a sample Release Drafter configuration there. It will be reviewed together with all current users so that we come up with a convenient Release Drafter configuration
3. Open discussion for other GitHub applications being used in jenkinsci. We could have global configs there as well

Would appreciate any feedback. If there is a consensus about having such global configuration repo, I am happy to implement it.

BR, Oleg

[Robert Sandell]

+1 I've been hoping we do something like this for a while now but haven't come up with anything myself :)

Though it states on the Release Draft App page: "Release Drafter requires full write, because GitHub does not offer a limited scope for only writing releases. Don't install Release Drafter to your entire GitHub account — only add the repositories you want to draft releases on."

/B

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDA%3DmXpKMz%3Dmo6qTYaAcrj56d0xJjQzOV2MtewdeCpgWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees, Inc.

E: rsan...@cloudbees.com

Twitter: robert_sandell

[Matt Sicker]

GitHub's terribly coarse security API to the forefront once again!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2%3DaU8EOdjbpDVRsnfx2CWCsdNyKoyQR1WmbtNLJpD5Vw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Matt Sicker
Senior Software Engineer, CloudBees

[Jesse Glick]

+1 from me as well. I guess we would consider it a separate though
related effort to actually standardize use of Release Drafter, so that
plugins.jenkins.io is able to obtain changelogs from the GitHub
release metadata rather than Confluence.

[Gavin Mogan]

I don't think the warning about release drafter really affects jenkins. Its all open source and public anyways.

+1 to standardising on using github releases. I started letting release drafter work and then copy the release notes to confluence just for backwards compability

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1gg%3DzKKPUvgajeDMznLeBHDh6AZa-UPfa%3Dgmk0vtKJpQ%40mail.gmail.com.

[Oleg Nenashev]

Security concern is indeed an issue there, same for Dependabot and other things. TL;DR: A malicious GitHUb app maintainer can push code to your repo.

AFAIK GitHub is well aware about this concern, and they are introducing more and more fine grain permissions.

Even if we put configs on a global level, I do not plan to add the application globally.

It will be still enabled on a per-repo basis after the explicit confirmation from maintainers that they understand the risks.

related effort to actually standardize use of Release Drafter, so that plugins.jenkins.io is able to obtain changelogs from the GitHub release metadata rather than Confluence. 

I also keep this story in mind, but we firstly need to get some adoption IMHO. 

BR, Oleg

On Thursday, May 23, 2019 at 5:57:15 PM UTC+2, Gavin Mogan wrote:

I don't think the warning about release drafter really affects jenkins. Its all open source and public anyways.

+1 to standardising on using github releases. I started letting release drafter work and then copy the release notes to confluence just for backwards compability

On Thu, May 23, 2019 at 8:16 AM Jesse Glick <jgl...@cloudbees.com> wrote:

+1 from me as well. I guess we would consider it a separate though
related effort to actually standardize use of Release Drafter, so that
plugins.jenkins.io is able to obtain changelogs from the GitHub
release metadata rather than Confluence.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

[Marky Jackson]

+1 from me

[James Nord]

If there was a way to release community plugins from our infra then you could do this with a simple command without the need to grant any permissions to apps.

"jx step changelog" / https://github.com/github-tools/github-release-notes are some possible commands but others exist too.

now we have the repository permission updater for artifactory, could we not re-use the same to grant committers access to "build" on a "release" job in the plugin folder (make the master branch parameterisable and have a build that takes a release paramter defaulted to false)?  The job is the trivial part, the harder bit is maybe the AuthN/AuthZ mapping and I'm not sure what ci.jenkinsci.org is actually using to know if this is feasable or not, or if there are other vectors that makes this unrealistic. 

/James

On Friday, May 24, 2019 at 10:42:08 AM UTC+1, Marky Jackson wrote:

+1 from me

[Oleg Nenashev]

If we speak about GitHub automation, it is easier to use GitHub Actions + Rekease Drafter. https://github.com/toolmantim/release-drafter#usage . Permission issue still applies, but at least you get more control of what's  being invoked

W.r.t automating releases from ci.jenkins.io, it is a longstanding topic :(

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/dOs8YRQwQiI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9fbad045-5ff4-41d9-98a1-b36ad446ae64%40googlegroups.com.

[Daniel Beck]

> On 24. May 2019, at 19:23, James Nord <jn...@cloudbees.com> wrote:
>
> If there was a way to release community plugins from our infra then you could do this with a simple command without the need to grant any permissions to apps.

I know of a proposal supposed to be landing soon related to that :)

[Oleg Nenashev]

Since there is a consensus in this thread, I went ahead and implemented this story:

• Default configuration: https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.yml
• Pull request which merges the configuration for BlueOcean and Configuration-as-Code plugins: https://github.com/jenkinsci/.github/pull/1
• Usage examples:
• Role Strategy plugin: https://github.com/jenkinsci/role-strategy-plugin/blob/master/.github/release-drafter.yml
• ci.jenkins.io-runner: https://github.com/jenkinsci/ci.jenkins.io-runner

Some notes about the current default config:

• Default tag template (tag-template)  does not make much sense, because Maven Release plugin in Plugin POM uses the ${artifactId}-${version} tag format by default. It needs to be overridden in repos (see the linked examples)
• Jenkins plugins use different versioning format. Release Drafter defaults to semver, but the majority of Jenkins plugins uses the two-digit version number. That;s why I used it as a default in the global config
• it can be also overridden in repos, see ci.jenkins.io-runner config
• Current replacer regexps target the common "[JENKINS-1234] - Change description" templates only, but we can extend the,

Obviously, contributions to the default template (and to other GitHub app templates) are more than welcome. If you want to try out Release Drafter in your repos, let me know. Disclaimer: see the permissions concerns above.

Best regards,

Oleg

[Jesse Glick]

On Sat, May 25, 2019 at 7:29 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> If you want to try out Release Drafter in your repos, let me know.

Certainly in `plugin-pom` and friends.

Can we just create a `.github/release-drafter.yml` and have it start
working, or is there some other step? A small guide in

https://github.com/jenkinsci/.github/blob/master/README.md

would be appreciated.

[Mark Waite]

I'd like to try it on the platformlabeler-plugin.

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6bab3eaa-e979-480e-b8c3-4b5425d600de%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks!

Mark Waite

[Oleg Nenashev]

I agree it makes sense to document the steps.

Basically it is...

1. Create ./github/release-drafter.yml file
• Extend the global config there
• Define your labeling and versioning scheme by overriding fields
• Examples:

• Role Strategy plugin: https://github.com/jenkinsci/role-strategy-plugin/blob/master/.github/release-drafter.yml
• ci.jenkins.io-runner: https://github.com/jenkinsci/ci.jenkins.io-runner

1. Create an INFRA ticket with component=github for enabling Release Drafter in the repo. Assign to Oleg to improve the response time

Order of steps does not really matter. I enabled Release drafter for Platform Labeler and Plugin POM

BR, Oleg

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/dOs8YRQwQiI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFQdkjd972M%3D8Zj3%3Ddf-upAXLV41vM_nGu7Dk1zjNHW6A%40mail.gmail.com.

[Tim Jacomb]

I’m pretty sure maintainers can just add the app themselves as it’s approved for the org, assuming they have admin permission on the repo

I didn’t need an infra ticket when I set it up on the slack plugin...

Thanks

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDnaquWT7RfmFukVWnyVmqHS_gCmDsbT28xBJjpgA0jxw%40mail.gmail.com.

[Oleg Nenashev]

We usually do not grant ADMIN role permissions to maintainers, but some plugins indeed use admin. I prefer to focus on a more common case in the guidelines

BR, Oleg

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bif%2BMusRivM2ycG-XhxybW8v%2BggVah3v4gj8FrA9txazsw%40mail.gmail.com.

[Tim Jacomb]

Afaik admin role is granted in general now, since the introduction of danger zone permission protection.

I’m admin on a plugin that was hosted a couple of months ago, without me asking for it at all...

Thanks

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCkQkhWM5UaFmoY1pA8K%2B9d5UztBEDtr21_weQqOYusZA%40mail.gmail.com.

[Daniel Beck]

> On 28. May 2019, at 22:37, Tim Jacomb <timja...@gmail.com> wrote:
>
> Afaik admin role is granted in general now, since the introduction of danger zone permission protection.

This is correct.

Obviously, many people have write access specifically, either because they were added while we had implemented the 'danger zone' workaround, or because they got their access as a replacement of the Everyone team which I cleaned up.

Check access at https://jenkins.io/doc/developer/publishing/source-code-hosting/

Request changes at https://issues.jenkins-ci.org/browse/INFRA

[Oleg Nenashev]

Meanwhile now we have more than 20 repositories with Release Drafter enabled.

I have created https://github.com/jenkinsci/.github/pull/8 to document usage in the jenkinsci organization (quick hack).

Any feedback will be appreciated.

[Oleg Nenashev]

UPD: User docs have been integrated and tested: https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.adoc

I plan to make a blogpost later, but I believe this story can be considered as completed for Jenkins plugin maintainers.

Whomever is interested, feel free to start using the tool!

Best regards,

Oleg

[Matt Sicker]

Thanks, Oleg!

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d62c3cbc-ccc8-49f4-b2c0-c4193f74c5dd%40googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.



--