-
-
Notifications
You must be signed in to change notification settings - Fork 106
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
json-extension: use an unique token for progress example #230
json-extension: use an unique token for progress example #230
Conversation
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.
Looks fine to me 😄
@dgreisen not sure what is up with these expected statuses... |
a5e7111
to
cf887ad
Compare
/cc @tombh |
I can't see what's going on with these expected CI status either 🫤 Maybe rebase master, CI config has changed a bit since the PR was submitted. Otherwise this is an easy LGTM |
cf887ad
to
a39bb9e
Compare
it was already rebased on master, but I thought "let's try again :)" so I changed the commit and I noticed that the "ci" workflow config does not run because it is configured to skip this ci workflow for paths in pygls/.github/workflows/ci.yml Lines 7 to 9 in 96bc69d
this pull request only change these paths, so this explains why the workflows did not run. Next question is why this prevents the merge ? Maybe this is because the branch must be marked as "protected" with a setting to only allow merging if these test pass ( https://github.saobby.my.eu.orgmunity/t/github-actions-pull-requests-always-include-some-outdated-checks/16157/2 seems a similar issue ). Do you have access to these settings, can you confirm that ? Thanks ! |
Well-spotted. I don't have access to those settings, as I discovered from similar issues in #223. We can ask @dgreisen if needs be. But my feeling is that the disadvantages of that So I vote for just removing those |
This was also my idea. There are also paths here: pygls/.github/workflows/json-extension.yml Lines 5 to 7 in 96bc69d
pygls/.github/workflows/json-extension.yml Lines 9 to 11 in 96bc69d
which if I understand correctly mean "don't run json extension test unless json extension is changed", but I feel it's better to run the tests anyway in that case, a change in pygls might introduce a regression that would only be revealed by the extension test. |
Yes, agreed. Do you want to push a commit with those lines removed then? |
Thanks @tombh I'll try to send a pull request with that, then we'll rebase this one on top |
By ignoring CI workflow when json extension is changed, we have a problem that the tests are not run and stay in *Expected — Waiting for status to be reported* state as we could see in openlawlibrary#230 Json extension tests were not run when only pygls code is changed, but it can also be interesting to run the test for the extension every time, because it acts as an integration test for pygls. This change the workflow to run all tests for every pull request or push, regardless of what code is changed.
Sorry, were you waiting on a review for this? |
By ignoring CI workflow when json extension is changed, we have a problem that the tests are not run and stay in *Expected — Waiting for status to be reported* state as we could see in #230 Json extension tests were not run when only pygls code is changed, but it can also be interesting to run the test for the extension every time, because it acts as an integration test for pygls. This change the workflow to run all tests for every pull request or push, regardless of what code is changed.
Ah yes, I remember. Ok merged #250. |
I guess this can be merged, we were waiting to have the test passing first, but tests are OK now it seems |
f29ff00
to
463a120
Compare
I was just about to merge this when I realised that this would be a good addition the changelog. Could you add it? I rebased master in, which is a force push. Which isn't good practice when collaborating on a branch, my apologies. I just thought I was on the point of merging. You can just force push yourself anyway, because all it is is the recent master branch changes. |
The spec [1] and pygls implementation [2] needs the token to be unique. By using an hardcoded token like this, the progress works only one time, the second time there's an error that token is already registered. 1: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverInitiatedProgress 2: https://github.com/openlawlibrary/pygls//blob/ee17487e4f40f971e7ec6f7711fa8334c5b7b127/pygls/progress.py#L28
463a120
to
2d2e776
Compare
Thanks @tombh and sorry for delay, I have finally added a changelog entry |
Great, thanks ✨ |
Released in https://pypi.org/project/pygls/1.0.1/ |
The spec 1 and pygls implementation 2 need the token to be unique.
By using an hardcoded token like this, the progress works only one time,
the second time there's an error that token is already registered.
Description (e.g. "Related to ...", etc.)
Please replace this description with a concise description of this Pull Request.
Code review checklist (for code reviewer to complete)