Skip to content

Make GitHub validator smarter#59

Merged
bwplotka merged 1 commit intobwplotka:mainfrom
saswatamcode:github-smarter
Jul 27, 2021
Merged

Make GitHub validator smarter#59
bwplotka merged 1 commit intobwplotka:mainfrom
saswatamcode:github-smarter

Conversation

@saswatamcode
Copy link
Copy Markdown
Collaborator

@saswatamcode saswatamcode commented Jul 10, 2021

This PR makes the special github validator smarter. This renames github validator to githubPullsIssues. (As discussed in 1:1.)

Configuration will now look like,

- regex: '(^http[s]?:\/\/)(www\.)?(gitlab\.com\/)thanos-io\/thanos(\/pull\/|\/issues\/)'
    type: 'githubPullsIssues'
- regex: '(^http[s]?:\/\/)(www\.)?(github\.com\/)thanos-io\/thanos(\/releases\/tag\/)'
    type: 'ignore'

This also avoids surprises by asking users to provide the correct regex so that mdox does not have to create it.

In case of faulty regex, below errors are shown,

For githubPullsIssues,

error: fmt command failed: parsing githubPullIssues Regex: GitHub PR/Issue regex not valid. Correct regex: (^http[s]?:\/\/)(www\.)?(github\.com\/){ORG_NAME}\/{REPO_NAME}(\/pull\/|\/issues\/)

@saswatamcode saswatamcode requested a review from bwplotka July 10, 2021 14:19
@saswatamcode saswatamcode self-assigned this Jul 10, 2021
Copy link
Copy Markdown
Owner

@bwplotka bwplotka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's .... too smart. Too smart for me 🙈

Some comments (: I think we talked about something different in 1:1.

But good direction! (:

// GitHub repo token to avoid getting rate limited.
Token string `yaml:"token"`
// Validators to be used alongside githubPullsIssues.
NPIValidators []NonPullsIssuesValidator `yaml:"nonPullsIssuesValidators"`
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm, I am not fan of this approach...

Reasons:

  • We are leaking GH special flow. It's actually quite surprise to guess what is the logic here
  • If you regex only fo pulls or issues how other links even get there? In your example I would expect only pulls and issues being matched here so nonXYZ thing will never get called (at least that's my perception)
  - regex: '(^http[s]?:\/\/)(www\.)?(gitlab\.com\/)thanos-io\/thanos(\/pull\/|\/issues\/)'
    type: 'githubPullsIssues'
    nonPullsIssuesValidators:
      - regex: '(^http[s]?:\/\/)(www\.)?(github\.com\/)thanos-io\/thanos(\/releases\/tag\/)'
      - regex: '(^http[s]?:\/\/)(www\.)?(github\.com\/)thanos-io\/thanos(\/blob\/)'
      - regex: '(^http[s]?:\/\/)(www\.)?(github\.com\/)thanos-io\/thanos(\/commit\/)'```

Do we need this. Why not simple approach of regexing pull and issues only (and erroring out when user passes non issue or non PR) then use ignore type to ignore further stuff? 🤔

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I was kind of mixing nested validators + pullsIssues which on second thought might make things super confusing 😅. ignore would be sufficient for the nonPullsIssues thing. Will remove this and just have githubPullsIssues. So example config would be,

  - regex: '(^http[s]?:\/\/)(www\.)?(gitlab\.com\/)thanos-io\/thanos(\/pull\/|\/issues\/)'
    type: 'githubPullsIssues'
  - regex: '(^http[s]?:\/\/)(www\.)?(github\.com\/)thanos-io\/thanos(\/releases\/tag\/)'
    type: 'ignore'

Signed-off-by: Saswata Mukherjee <saswataminsta@yahoo.com>
Copy link
Copy Markdown
Owner

@bwplotka bwplotka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, let's go!

@bwplotka bwplotka merged commit 6c9c3f7 into bwplotka:main Jul 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants