.github/CONTRIBUTING.md · mamh-java/github-branch-source-plugin

代码拉取完成,页面将自动刷新

richgiteeai

Watch

不关注关注所有动态仅关注版本发行动态关注但不提醒动态

1 Star 0 Fork 0

mamh-java/github-branch-source-plugin

代码 Issues 0 Pull Requests 0 Wiki 统计流水线

服务

加入 Gitee

与超过 1400万开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)

免费加入

已有帐号? 立即登录

文件

master

分支 (103)

标签 (164)

管理

master

dependabot/maven/io.jenkins.tools.bom-bom-2.541.x-6549.v96f8c826373f

1967.x

dependabot/maven/org.wiremock-wiremock-standalone-3.13.2

dependabot/maven/org.jenkins-ci.plugins-plugin-5.9

dependabot/maven/org.awaitility-awaitility-4.3.0

dependabot/maven/io.jenkins.tools.bom-bom-2.479.x-4228.v0a_71308d905b_

dependabot/maven/io.jenkins.tools.bom-bom-2.440.x-3435.v238d66a_043fb_

dependabot/maven/org.jenkins-ci.plugins-plugin-4.85

dependabot/maven/org.jenkins-ci.plugins-plugin-4.82

dependabot/maven/io.jenkins.tools.bom-bom-2.414.x-2982.vdce2153031a_0

dependabot/maven/org.jenkins-ci.plugins-plugin-4.80

dependabot/maven/io.jenkins.tools.bom-bom-2.414.x-2907.vcb_35d6f2f7de

bitwiseman-noop-patch-4

dependabot/maven/io.jenkins.tools.bom-bom-2.387.x-2483.v3b_22f030990a_

dependabot/maven/io.jenkins.tools.bom-bom-2.387.x-2446.v2e9fd3b_d8c81

dependabot/maven/org.jenkins-ci.plugins-plugin-4.71

dependabot/maven/io.jenkins.tools.bom-bom-2.387.x-2258.v522c10b_d4695

dependabot/maven/io.jenkins.tools.incrementals-git-changelist-maven-extension-1.7

dependabot/maven/org.jenkins-ci.plugins-plugin-4.67

1967.1969.v205fd594c821

1967.vdea_d580c1a_b_a_

1936.vfa_a_5c2cef4e7

1934.v23cf60a_47fc3

1925.v62fb_7ffb_08ce

1917.v9ee8a_39b_3d0d

1911.vc09e01781005

1910.v4ca_b_2c639cb_0

1906.v21c5c13d25c6

1871.v50ffb_786515e

1869.vdb_846d75405b_

1864.v411feec5e78e

1862.v1a_fc22a_d3788

1848.v42f74f7f4500

1844.v4a_9883d49126

1834.v857721ea_74c6

1833.v77b_6542df5a_8

1824.v046257273408

1822.v9eec8e5e69e3

1815.v9152b_2ff7a_1b_

克隆/下载

HTTPS SSH SVN SVN+SSH 下载ZIP

提示

下载代码请复制以下命令到终端执行

为确保你提交的代码身份被 Gitee 正确识别,请执行以下命令完成配置

git config --global user.name userName 
git config --global user.email userEmail

初次使用 SSH 协议进行代码克隆、推送等操作时,需按下述提示完成 SSH 配置

1 生成 RSA 密钥

2 获取 RSA 公钥内容,并配置到 SSH公钥中

在 Gitee 上使用 SVN,请访问使用指南

使用 HTTPS 协议时,命令行会出现如下账号密码验证步骤。基于安全考虑,Gitee 建议配置并使用私人令牌替代登录密码进行克隆、推送等操作

Username for 'https://gitee.com': userName

Password for 'https://userName@gitee.com': # 私人令牌

分支 103

标签 164

github-branch-source-plugin

.github

CONTRIBUTING.md

CONTRIBUTING.md 5.91 KB

# Contributing to GitHub Branch Source
Community pull requests are encouraged and welcomed! Following are some guidelines for what to expect.

## Getting started
For information on contributing to Jenkins in general, check out the 
[Beginner's Guide](https://wiki.jenkins-ci.org/display/JENKINS/Beginners+Guide+to+Contributing) to contributing to 
Jenkins. Also, please make sure to read the [Jenkins Code of Conduct](https://jenkins.io/project/conduct/). The main 
[jenkins.io website](https://jenkins.io/doc/developer) has lots of information about developing and extending Jenkins, 
including several [how-to guides](https://jenkins.io/doc/developer/guides/) about plugin development.

## Being careful

GitHub Branch Source is one of the most widely used plugins in the Jenkins plugin catalog. 
It is relied upon by hundreds of thousands of people worldwide. Because of this huge install 
base, caution must be exercised when making changes. Code changes are reviewed 
with a high level of scrutiny, out of necessity. This level of thoroughness should not be interpreted 
as a personal attack. (And, of course, if someone feels it is a personal attack, that's why we have the 
[Code of Conduct](https://jenkins.io/project/conduct/) in place).

## How to submit your contribution

Changes should come in the form of pull requests to the master branch of the main repository. Contributors 
may do so from the origin repository, e.g. 
`https://github.com/jenkinsci/github-branch-source-plugin`, or from their own fork, e.g. 
`https://github.com/firstTimeContributor/github-branch-source-plugin`.

Changes should never be made directly to master. This holds true for all contributions, 
no matter the person or the change. Pull requests allow for easy code review.

High-impact security patches may sometimes follow an accelerated process. The 
[Jenkins Security team's process](https://jenkins.io/security/) describes how to report, and 
work on, security vulnerabilities in Jenkins plugins.

Any new functionality, API changes, or bug fixes must include adequate automated test coverage. 
If you feel that your pull request does not need its own test coverage, state this in 
the description, including the reason(s) why.

Please use human-readable commit messages. When your code is being reviewed, a commit message like 
`Add unit test for whizBang.getSomethingAwesome` is far more useful than `testcase`.

If your PR relies on open PRs in other plugins, please include references to them in your 
PR. This makes it easy for reviewers to navigate between all of the relevant PRs.

## Associating changes with existing Jira issues

If your PR is in response to an existing issue (bug, improvement, etc) in 
[the Jenkins JIRA](https://issues.jenkins-ci.org/secure/Dashboard.jspa), include the issue 
key in the subject line, with `[` `]` square brackets surrounding it. For example,
`[JENKINS-12345] Improve GitHub Branch Source with fluxCapacitor module`. This keeps the issue 
easy to see in what can become a long list of PRs.

## Creating a new Jira issue for your contribution

When proposing new features or enhancements, potential contributors should file a Jira issue first, 
describing their proposed changes and potential implementation details. Consensus can be reached in 
the Jira issue before the PR is filed. This prevents surprising plugin maintainers, and prevents 
contributors from having large amounts of work refused.

Trivial changes might not warrant filing a Jira issue; although there is no harm in filing 
one anyway. Larger changes, which have noticeable impact on your fellow users and developers, 
should always have a Jira issue filed for them. This Jira issue serves as a centralized 
location for discussion about the change.

To give a sense of what constitutes a trivial change versus a larger one, here are some examples. 
This is not intended to be an all-inclusive list, but it should give an idea:

| Trivial Changes, no Jira needed | Larger Changes, file a Jira | 
| --------------------------------|-------------------------------|
| Additional test coverage | Entirely new functionality |
| Spelling, Grammar, other typos | API Changes |
| Edits to inline help | New or updated dependencies |
| Cleaning up of unused imports | User Interface changes |

## Testing your changes

Before submitting your pull request, it needs to have been tested. This may take the form of 
the automated tests you've included in your pull request - _you did include tests, right?_ 
To run your tests locally, simply building the plugin via `mvn clean install` will run all 
of its tests locally.

Additionally, manual testing is welcomed and encouraged. If you've done some particularly clever 
testing of your changes, please describe that in the description of your pull request, so that 
your reviewers know what's already been done.

Once submitted, your change will be built, and the plugin's tests will get run, on 
[ci.jenkins.io](https://ci.jenkins.io). GitHub will be notified of the results of this build, 
so you don't need to follow up and look for yourself. Your changes will be tested with combinations 
of Java 8 and 11, on Linux and Windows.

## The code review process

We promise to be thoughtful, professional, and reasonable, and the same is expected of all 
contributors. [Jenkins has a Code of Conduct](https://jenkins.io/project/conduct/), and we 
take that seriously. We want the Jenkins community to be an open and welcoming one, for all 
contributors, no matter how seasoned.

In order to have your PR merged or considered for merging, you must respond to all actionable 
feedback.

## Merging and releasing

The process by which pull requests get merged to master is fairly simple, and is described 
in the [guide for releasing a plugin](https://jenkins.io/doc/developer/publishing/releasing/).
In short, once changes are merged to master, a release can be generated. Final decisions 
on merging and releasing fall to the plugin's maintainer.

一键复制编辑原始数据按行查看历史

Karl Shultz 提交于 2020年02月12日 10:26 +08:00 . Add an if