Track generated stubs for docstub itself #96
Merged
+651
−6
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I thought about not doing this but then it becomes more complicated to include the stubs into the package in the release workflow (cd.yml). I want to keep the release workflow as minimal as possible to reduce the risk of a supply chain attack. This approach sidesteps that problem, because the stubs are already there and tracked. However, we need to assert that the tracked stubs are identical with the docstub generated ones. That is a bit tricky, because `git diff` actually ignores untracked files! So I came up with `assert-unchanged.sh`. I really struggled with this becaue I initally tried to use git ls-files with the "-z" option which returns null-delimited paths. I couldn't figure out how to pass them to `git add` and `git unstage` later on. I'm worried that this approach is a bit brittle (due to `assert-unchanged.sh`) and increases the diff in PRs. On the other hand being able to review the stubs is probably not a bad thing. We'll see how that goes.
This reverts commit b09317d.
Apparently this works fine with mypy and basedpyright!
I think that triggered a permission denied error in the GitHub CI. This solution feels a lot cleaner too!
*facepalm*
lagru
added
devops
lagru
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I thought about not doing it this way but then it becomes more complicated to include the stubs into the package in the release workflow
cd.yml. I want to keep the release workflow as minimal as possible to reduce the risk of a supply chain attack.This approach sidesteps that problem, because the stubs are already there and tracked. However, we need to assert that the tracked stubs are identical with the docstub generated ones. That is a bit tricky, because
git diffactually ignores untracked files! So I came up withassert-unchanged.sh. I really struggled with this becaue I initally tried to use git ls-files with the "-z" option which returns null-delimited paths. I couldn't figure out how to pass them togit addandgit unstagelater on.I'm worried that this approach is a bit brittle (due to
assert-unchanged.sh) and increases the diff in PRs. On the other hand being able to review the stubs is probably not a bad thing. We'll see how that goes.Release note
For maintainers and optionally contributors, please refer to changelist's README on how to document this PR for the release notes.