Add whitelist label option.

[sjstyle]

This adds the Whitelist label option to ghprb's advanced options.

• If both Whitelist and Blacklist label options are entered, it works in 'AND' mode. In other words, PR should not have Blacklist label and Whiltelist label should exist.

• If nothing is entered in the Whitelist label option, this option is ignored.

I think adding the Whitelist label option can help solve the #210 issue in the future.

• Bug Fix Included (Retest PR cause Github API call failed with 404 #441)

1. LabelField's empty string check problem.

Https://github.com/sjstyle/ghprb-plugin/commit/c54a32cb01d897c207a1f531aa3873f8ab70e044#diff-4b618248c9f9a59094a30a1212e2d172R170

Previously this plug-in did not check for Empty on this line. As a result, when the user enters a setting value, a non-null space is input, so the empty collection is always returned and the Label Check part is activated.

2. pr.getLabels method problem.

Https://github.com/sjstyle/ghprb-plugin/commit/c54a32cb01d897c207a1f531aa3873f8ab70e044#diff-70706d3124e337b7f717ad901c08d53aL178

Previously this plugin called the pr.getLabels () method. It seems that we would expect only the labels to be returned because of the get prefix, but in fact this method is supposed to do something else.

Https://github.com/kohsuke/github-api/blob/github-api-1.80/src/main/java/org/kohsuke/github/GHPullRequest.java#L130-L133

This is where calling fetchIssue ().

https://github.com/kohsuke/github-api/blob/github-api-1.80/src/main/java/org/kohsuke/github/GHPullRequest.java#L297-L302

It changes this in this part. This changes the object from <api> / {user} / {repo} / pulls to <api> / {user} / {repo} / issues.

I think this is supposed to be the #441 problem.

[benpatterson]

Hi @sjstyle thanks a lot for the pull request!

Could you also add some tests that go over some of the different conditions/use cases? For example,

• Whitelist is set and blacklist is not set (and vice versa)
• Both whitelist and blacklist are set
• And then various matches of the above for the pull request...

[sjstyle]

Our team is developing web applications in the company. The team is using the GitHub Pull Request builder for two purposes. (I have created two GitHub Pull Request Projects.)

First, run the test automatically for each pull request to ensure that the test did not fail. It is reasonable to run the test on every commit, and I think it is good because there is no need to leave a comment.

Second, when you open a pull request to get a quick result, Docker Container Build is executed and the URL that can check the result is left as a comment.

During this process, several Pull Requests were created, and Docker Build was executed for every commit, so the URL Comment that the Pull Request Builder left on success came as much as spam. (If we do not leave a URL in the comment, we will not know which URL will allow access to the Container, as there are multiple Docker Servers in our team.)

In most back-end development, there was a desire to have Docker Build run only in pull requests that the "team wants" because it can be checked to see if it was created correctly as a test. However, the function "AS-IS" in the plug-in was all "Blacklist Label", which was the conclusion that it was necessary to explicitly attach a specific label when creating most pull requests.

To improve this inconvenience, I developed "Triggering only whitelist labels" feature and labeled it "Docker Build" so that the Docker Build Trigger responded. This makes it possible for the team to attach a label to only the pull requests that they want to check for results, thereby reducing unnecessary builds and resource consumption.

[sjstyle]

Oh, I misunderstood. I'll add some test soon.

[sjstyle]

@benpatterson
I add whitelist label test, whitelist and blacklist label test.

[benpatterson]

CC @udisch

@sjstyle I suggest you rebase on top of #449. We can focus on getting that done, then we can look at adding a whitelist.

[benpatterson]

Oh, and instead of rebasing, it might be easier to create a new PR off of that branch. Whatever is easier for you and however comfortable you are with git.

[sjstyle]

@benpatterson
I just rebased re-implement-label-support-ignorelist branch. (I think it is easier than make new pull request) If you think it is better make new PR rather than rebase, I will make new PR tomorrow. (My local time now is 01:00AM..)

I'll back soon.

[vad1m]

hi guys, I'm excited about that feature! Can we add it asap to the plugin and release new version? Looking forward to see it next days 👍

[sjstyle]

@benpatterson
I removed check dirty pull request logic and upgrade github-api version.

[benpatterson]

Hi Sang - Great. I'll plan to give it a look this week. ​

[benpatterson]

@sjstyle Ok this is coming along. Could you add job DSL support?

CC @udisch as well.

I'm planning on putting everything together in a PR like #455, but neither of you would have access to that branch, so you'd have to develop on one of your forks. Thanks again for the help.

[sjstyle]

@benpatterson
I have no write access on this repository, so I added some commit in this pull request.
And, I think GitHub is better than Github, So I made new casing commit instead of using yours.
I also added JobDsl support, but I didn't test it. (Our team using only webhook trigger...)

[benpatterson]

Thanks @sjstyle I'm taking a look.

[benpatterson]

@sjstyle just pinging. I'm still working on this. I think we'd be better off if the job DSL for labels could accept a list, much like the other white/black lists. That's what I'm working on.

[benpatterson]

Merged as part of #464

Thanks again for the help.