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

934: Bots incorrectly assigned "build" label despite no obvious matching rule #1118

Closed
wants to merge 1 commit into from

Conversation

rwestberg
Copy link
Member

@rwestberg rwestberg commented Apr 14, 2021

When determining the set of file names to evaluate for determining label assignment, only include the source name for deletions and renames (and not for copies, for example).


Progress

  • Change must not contain extraneous whitespace
  • Change must be properly reviewed

Issue

  • SKARA-934: Bots incorrectly assigned "build" label despite no obvious matching rule

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/skara pull/1118/head:pull/1118
$ git checkout pull/1118

Update a local copy of the PR:
$ git checkout pull/1118
$ git pull https://git.openjdk.java.net/skara pull/1118/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1118

View PR using the GUI difftool:
$ git pr show -t 1118

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/skara/pull/1118.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Apr 14, 2021

👋 Welcome back rwestberg! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot changed the title 934 934: Bots incorrectly assigned "build" label despite no obvious matching rule Apr 14, 2021
@openjdk openjdk bot added the rfr label Apr 14, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Apr 14, 2021

Webrevs

@erikj79
Copy link
Member

@erikj79 erikj79 commented Apr 14, 2021

So in the PR listed in the bug, it was most likely this new file that Git implicitly assumed was a copy of an existing plist file because the initial content looked similar enough. We have such plist files under build directories so that's why the build label was added. Sneaky.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/sandbox.plist

@openjdk
Copy link

@openjdk openjdk bot commented Apr 14, 2021

@rwestberg This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

🔍 One or more changes in this pull request modifies files in areas of the source code that often require two reviewers. Please consider if this is the case for this pull request, and if so, await a second reviewer to approve this pull request before you integrate it.

🌎 Applicable reviewers for one or more changes in this pull request are spread across multiple different time zones. Please consider waiting with integrating this pull request until it has been out for review for at least 24 hours to give all reviewers a chance to review the pull request.

After integration, the commit message for the final commit will be:

934: Bots incorrectly assigned "build" label despite no obvious matching rule

Reviewed-by: erikj

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label Apr 14, 2021
@rwestberg
Copy link
Member Author

@rwestberg rwestberg commented Apr 15, 2021

Yes, that was indeed the case! Perhaps I should mention that it was actually @edvbld who figured it out.. :) So the diff we looked at was (dropped a few similar entries):

> git diff 15bcf6d9 0bce6a53 --find-renames=90% --find-copies=90% --find-copies-harder --name-status
M       src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxAppImageBuilder.java
R100    src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/java32.png       src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/JavaApp.png
M       src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppBundler.javarces_ja.properties
M       src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties
A       src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/product-def.plist
C091    make/data/macosxsigning/java.plist      src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/sandbox.plist
M       src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java
M       src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WindowsAppImageBuilder.java
R100    src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/java48.ico     src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/JavaApp.ico
M       test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherIconVerifier.java

So there was indeed a "copy" that seemed to come from the make folder..

@rwestberg
Copy link
Member Author

@rwestberg rwestberg commented Apr 15, 2021

/integrate

@openjdk openjdk bot closed this Apr 15, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Apr 15, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 15, 2021

@rwestberg Pushed as commit 132acee.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants