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

[JENKINS-49387][JENKINS-49520] - Validation errors #3292

Merged
merged 2 commits into from Feb 18, 2018

Conversation

4 participants
@ksenia-nenasheva
Copy link
Contributor

commented Feb 14, 2018

See JENKINS-49387 and JENKINS-49520.

In the PR#3141 I broke validation for some fields.
This PR:

  • restores old rules for validation
  • applies new rules for fields which are mandatory

Proposed changelog entries

  • Entry 1: Prevent input validation errors in optional numeric form entries (regression in 2.105).
  • ...

Submitter checklist

  • JIRA issue is well described
  • Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change). Examples
    * Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
  • Appropriate autotests or explanation to why this change has no tests
  • For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

@ksenia-nenasheva

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2018

@oleg-nenashev
Copy link
Member

left a comment

LGTM

@oleg-nenashev

This comment has been minimized.

Copy link
Member

commented Feb 14, 2018

@jenkinsci/code-reviewers this is a regression in 2.105 which impacts the current LTS baseline candidate (2.107). Would be great to get reviews so that we could merge it into the next weekly

@MarkEWaite
Copy link
Contributor

left a comment

Looks good to me. I had to think more deeply than usual about the regular expressions, but as far as I can tell, they are correctly expressing the intended match.

"INPUT.positive-number" : function(e) {
registerRegexpValidator(e,/^(\d*[1-9]\d*|)$/,"Not a positive integer");

This comment has been minimized.

Copy link
@daniel-beck

daniel-beck Feb 14, 2018

Member

Allowed to begin with leading zeroes why?

This comment has been minimized.

Copy link
@MarkEWaite

MarkEWaite Feb 14, 2018

Contributor

I assumed it was because a leading 0 with at least one non-zero digit is a valid positive integer.

We don't accept octal constants or hex constants, so the leading zero is harmless (and thus should be allowed) - my opinion.

This comment has been minimized.

Copy link
@ksenia-nenasheva

ksenia-nenasheva Feb 14, 2018

Author Contributor

I just restored the original behavior (see #3141).

This comment has been minimized.

Copy link
@daniel-beck

daniel-beck Feb 14, 2018

Member

Right, but specifically \d* doesn't seem right. Accepting empty values seems fine to restore compatibility, but this? Unclear to me, why.

This comment has been minimized.

Copy link
@ksenia-nenasheva

ksenia-nenasheva Feb 15, 2018

Author Contributor

I don't think it's critical. If you think it is necessary, I'll delete \d*.

This comment has been minimized.

Copy link
@MarkEWaite

MarkEWaite Feb 15, 2018

Contributor

@daniel-beck the pattern as a whole does not accept empty values. It requires at least one digit from the set 1-9.

I am fine if we disallow a leading zero (thus allowing deletion of the initial \d*). The regular expression will need to have some portion which accepts zero or more digits, but if you feel that leading zeros are not needed, I think it is fine to remove the first \d*.

This comment has been minimized.

Copy link
@daniel-beck

daniel-beck Feb 15, 2018

Member

the pattern as a whole does not accept empty values.

Not true. That's the whole reason there's parens around the digits.

^(\d*[1-9]\d*|)$
             ^^

This comment has been minimized.

Copy link
@MarkEWaite

MarkEWaite Feb 15, 2018

Contributor

Ah, you're correct. Sorry about my poor parsing of the regular expression.

I think an empty field should be allowed so that a default value is assumed when none is provided.

I am indifferent whether leading zeros should be accepted.

@oleg-nenashev

This comment has been minimized.

Copy link
Member

commented Feb 17, 2018

@daniel-beck @MarkEWaite What is your decision about that? Since it restores the original behavior, I would suggest merging it as is for backporting to 2.107.1 AND creating a follow-up ticket for your concerns

@MarkEWaite

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2018

I approve merging and backporting. I just saw an instance today of this bug. Once this is backported or available in a new weekly, I can test to confirm it is working as expected.

The problem case I saw was an intentionally empty field which was showing a red warning that it was not a positive integer.

@daniel-beck

This comment has been minimized.

Copy link
Member

commented Feb 17, 2018

@oleg-nenashev Seems reasonable.

@oleg-nenashev

This comment has been minimized.

Copy link
Member

commented Feb 17, 2018

@oleg-nenashev oleg-nenashev merged commit 5c8cc45 into jenkinsci:master Feb 18, 2018

1 check passed

continuous-integration/jenkins/pr-head This commit looks good
Details

@dwnusbaum dwnusbaum referenced this pull request Feb 20, 2018

Closed

[FIXED JENKINS-41182] - Support nodes with 0 executors #2925

0 of 4 tasks complete

olivergondza added a commit that referenced this pull request Feb 28, 2018

[JENKINS-49387][JENKINS-49520] - Validation errors (#3292)
* Fixes for validation

* Fix for an empty agent.nExecutors

(cherry picked from commit 5c8cc45)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.