-
Notifications
You must be signed in to change notification settings - Fork 179
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
[CI] split conda recipes and linting to separate files in azure pipelines #2238
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Flags with carried forward coverage won't be shown. Click here to find out more. |
.ci/pipeline/linting.yml
Outdated
versionSpec: $(PYTHON_LINT_VERSION) | ||
addToPath: true | ||
- script: | | ||
python -m pip install --upgrade pip setuptools |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it possible to re-use the pre-commit hook?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
This reverts commit a227d5a.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's wait for green tickets in the new CI entries now.
@david-cortes-intel step 4 on their website details the approach taken. https://pre-commit.com/ This PR is starting to have feature creep. |
@david-cortes-intel thanks for the reviews, It does look now better than it was, especially with the grep hacking gone. |
Description
This follows the conventions already existing in the codebase to simplify the analysis of CI and maintenance of the azure pipelines in sklearnex, this matches conda environment CI jobs in sklearnex.
No performance analysis required.
PR should start as a draft, then move to ready for review state after CI is passed and all applicable checkboxes are closed.
This approach ensures that reviewers don't spend extra time asking for regular requirements.
You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way.
For example, PR with docs update doesn't require checkboxes for performance while PR with any change in actual code should have checkboxes and justify how this code change is expected to affect performance (or justification should be self-evident).
Checklist to comply with before moving PR from draft:
PR completeness and readability
Testing
Performance