Restore custom distutils handling for resolving paths to submodules.#1386
Restore custom distutils handling for resolving paths to submodules.#1386cdce8p merged 15 commits intopylint-dev:mainfrom
distutils handling for resolving paths to submodules.#1386Conversation
|
I wonder how we can fully test this.. @cdce8p What do you think? Try this and see if the problems go away? |
I mean, we could add the CI step in this PR if we really want to have an extra workflow that only runs one corner case! |
distutils handling for resolving paths to submodules.distutils handling for resolving paths to submodules.
Pierre-Sassoulas
left a comment
There was a problem hiding this comment.
Thank you @jacobtylerwalls. We just need to remove the temporary CI job before merging, right ?
Co-authored-by: Pierre Sassoulas <pierre.sassoulas@gmail.com>
|
Do we though? Won't the CI job be a nice test to see this actually works? |
|
Fine with me. I added caching to make it more efficient. |
This reverts commit ed6c8f1.
There was a problem hiding this comment.
The change looks like it should work! I'm just not sure that we should run the CI job for every time. It's excellent to have but maybe better as part of an optional CI suite?
What do you guys think about moving it to a separate workflow file and using the workflow_dispatch event to trigger it whenever we need to? For that case, it would make sense to add a small comment in the code mentioning the workflow and that it can be run manually. Lastly, the caching could probably be removed. Although slightly more efficient, it can also create unexpected issues. If only run on request, there likely won't be any cache which can be restored to begin with.
https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
An alternative would be to add if: false to the job. It would also be trivial to change it to true whenever we need to work on it (which itself shouldn't be all too often).
After writing this, I'm just slightly leaning towards the latter option.
|
I'm thinking along the lines of the former option: what about creating a "release testing" CI workflow with |
Had another idea after reading "release testing", why not trigger on push of tags and |
The issue is then that we can tag buggy commit and have nothing released. Removing or renaming a tag and its associated milestone, then fixing the issue and doing another tag if something fail is more complicated than just launching locally. |
The idea was to have run automatically for every release. I still wanted to keep the manual trigger. |
|
Thanks @jacobtylerwalls 🐬 |
|
@ everybody, do we want to test this as well in |
Yeah, let's close the |
Steps
Description
I understand @DanielNoord wants to bisect before evaluating a path forward. But this test case fails without these changes, so it could be a sufficient way forward.
Type of Changes
Related Issue
Closes pylint-dev/pylint#5645