[JENKINS-65462] Do NOT trigger jobs for changes that status != GerritChangeStatus.NEW

[chenhuahuan]

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your master branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[chenhuahuan]

See: https://issues.jenkins.io/browse/JENKINS-65462

[rsandell]

Why?
The ticket doesn't seem to explain what the problem is and what the code fixes.
I would also like to see a unit test that recreates the issue.

[chenhuahuan]

Why?
The ticket doesn't seem to explain what the problem is and what the code fixes.
I would also like to see a unit test that recreates the issue.

---

1. Just updated the ticket with more detail.
2. Unit test brings too much extra work for me because the modified function doesn't have a unit test itself.

Please take a look at the ticket description , you will understand the issue and why this Pull Request fixs it.

[rsandell]

I am getting a lot of connection timeouts in the existing unit tests with this "fix" applied.

[chenhuahuan]

Doesn't make sense. What the timeout is about? It seems not related to the modification, is it some kind of CI environment issue?

[rsandell]

The timeout is about the tests not running for too long time, and there are many of the unit/integration tests that fires a new event and waits for the build to start. So if the build doesn't start then it will wait until the test times out.

Which indicates that this change breaks a lot of assumptions about how the triggering is supposed to work.

[ckreisl]

The check if it's in state "NEW" might be at the wrong location. I think i got the idea why it should be in.
It's also related to the topic handling PR #468 in my name.

The first question is "When is a change interesting?"
For "Patchset Created" events the state should be always NEW.
In case the change gets abandoned during runtime an exception is raised that the plugin can't set a +/- 1 verified anymore after build completion.

But one might be interested in ref updated "MERGED" events.
In my case it gets interesting with enabled "Topic Association". From my current point of view changes assigned to a topic which are already "MERGED" or "ABANDONED" shouldn't be taken into account. That's why we should only check for the "NEW" state.

I already started to do some adaption but it's not finalized yet.

[rsandell]

was this superseded by #481 ?