Replies: 2 comments 11 replies
-
|
Perhaps we should clarify in which situation what would be reviewed exactly. From they context of #66, I'm continuing with the assumption that the use case is reviewing a package addition to a PC channel.json or repository.json file (default or not). Imo, only looking at the repo HEAD is not going in the right direction for several reasons:
|
Beta Was this translation helpful? Give feedback.
11 replies
-
|
We've got a PR for a reviewer that works on packages. It's the best approach and apparently we are capable of such things. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
From the discussion in #66, from #66 (comment) onwards, about what the a new package review tool (to be used in the default channel and registries like those for LSP and SublimeLinter) should do.
Maybe leave this here for some time so others can respond and maybe have different ideas. And I might be missing use cases here.
But I would propose this:
The GitHub workflow supports open source projects only and will run the package tests on a git repository HEAD, ie. the one linked in the details key. If tests need to be run on a "compiled" package instead, this can be done outside of CI by downloading a package zip and feeding it into the review tool locally on a command line.
Running the review workflow on packages, not just a repo HEAD, complicates the tools needed to do so, and requires tags to be created for each test (making iterative improvements harder). In other words, it would lead to a more elegant tool and it would have practical benefits if we simply inspect a repository instead of a package.
There is no immediate urgency to decide something, but the tools we use need work at some point. So, if anyone has any related thoughts, let's discuss for a moment.
Beta Was this translation helpful? Give feedback.
All reactions