playwright: upgrade dependency #12141
Merged
Conversation
This file contains 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
vince-fugnitto
added
dependencies
|
Edit: the dependency has been approved. |
marcdumais-work
added a commit
that referenced
this pull request
Feb 6, 2023
Suring CI we run `dash-licenses` to check that the project's 3PP dependencies are approved by the Eclipse foundation. When a PR originates from the main repo, a token is available that permits running the tool in "automated review mode", which opens IP tickets automatically towards the Eclipse Foundation. When a PR originates from elsewhere, that token is not available and so we fall-back to reporting issues in the CI log. Until now, the "-project" option of `dash-licenses` was only thought useful un "automated review" mode, but it turns-out there is a rare case where we benefit providing this information all the time: when a 3PP dependency was narrowly approved, for use in Eclipse Theia only. here is one such dependency: https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/2734 The dependency above is part of a recent PR from an outside contributor (non-committer), that originated from a fork: #12141 So far, for PRs originating from a fork, we would not provide the project when running `dash-licenses` and so such dependency are incorrectly flagged as unapproved: https://github.com/eclipse-theia/theia/actions/runs/4075784869/jobs/7077702838#step:5:186 This commit provides the project all the time, so that such dependencies will be correctly assessed, based on what's approved for our project, even for non-committer contributors. Signed-off-by: Marc Dumais <[email protected]>
marcdumais-work
added a commit
that referenced
this pull request
Feb 6, 2023
During CI we run `dash-licenses` to check that the project's 3PP dependencies are approved by the Eclipse foundation. When a PR originates from the main repo, a token is available that permits running the tool in "automated review mode", which opens IP tickets automatically towards the Eclipse Foundation. When a PR originates from elsewhere, that token is not available and so we fall-back to reporting issues in the CI log. Until now, the "-project" option of `dash-licenses` was only thought useful un "automated review" mode, but it turns-out there is a rare case where we benefit providing this information all the time: when a 3PP dependency was narrowly approved, for use in Eclipse Theia only. here is one such dependency: https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/2734 The dependency above is part of a recent PR from an outside contributor (non-committer), that originated from a fork: #12141 So far, for PRs originating from a fork, we would not provide the project when running `dash-licenses` and so such dependency are incorrectly flagged as unapproved: https://github.com/eclipse-theia/theia/actions/runs/4075784869/jobs/7077702838#step:5:186 This commit provides the project all the time, so that such dependencies will be correctly assessed, based on what's approved for our project, even for non-committer contributors. Signed-off-by: Marc Dumais <[email protected]>
1 task
marcdumais-work
added a commit
that referenced
this pull request
Feb 6, 2023
During CI we run `dash-licenses` to check that the project's 3PP dependencies are approved by the Eclipse foundation. When a PR originates from the main repo, a token is available that permits running the tool in "automated review mode", which opens IP tickets automatically towards the Eclipse Foundation. When a PR originates from elsewhere, that token is not available and so we fall-back to reporting issues in the CI log. Until now, the "-project" option of `dash-licenses` was only thought useful in "automated review" mode, but it turns-out there is a rare case where we benefit providing this information all the time: when a 3PP dependency was narrowly approved, for use in Eclipse Theia only. Here is one such dependency: https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/2734 The dependency above is part of a recent PR from an outside contributor (non-committer), that originated from a fork: #12141 So far, for PRs originating from a fork, we would not provide the project when running `dash-licenses` and so such dependency are incorrectly flagged as unapproved: https://github.com/eclipse-theia/theia/actions/runs/4075784869/jobs/7077702838#step:5:186 This commit provides the project all the time, so that such dependencies will be correctly assessed, based on what's approved for our project, even for non-committer contributors. Signed-off-by: Marc Dumais <[email protected]>
marcdumais-work
added a commit
that referenced
this pull request
Feb 6, 2023
During CI we run `dash-licenses` to check that the project's 3PP dependencies are approved by the Eclipse foundation. When a PR originates from the main repo, a token is available that permits running the tool in "automated review mode", which opens IP tickets automatically towards the Eclipse Foundation. When a PR originates from elsewhere, that token is not available and so we fall-back to reporting issues in the CI log. Until now, the "-project" option of `dash-licenses` was only thought useful in "automated review" mode, but it turns-out there is a rare case where we benefit providing this information all the time: when a 3PP dependency was narrowly approved, for use in Eclipse Theia only. Here is one such dependency: https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/2734 The dependency above is part of a recent PR from an outside contributor (non-committer), that originated from a fork: #12141 So far, for PRs originating from a fork, we would not provide the project when running `dash-licenses` and so such dependency are incorrectly flagged as unapproved: https://github.com/eclipse-theia/theia/actions/runs/4075784869/jobs/7077702838#step:5:186 This commit provides the project all the time, so that such dependencies will be correctly assessed, based on what's approved for our project, even for non-committer contributors. Signed-off-by: Marc Dumais <[email protected]>
|
@ndoschek do you mind rebasing to pick up #12151? It should fix the issue where |
Update `playwright` to the latest version (and open up version range) as there was a breaking change regarding playwright's Page object. Signed-off-by: Nina Doschek <[email protected]>
ndoschek
force-pushed
the
ndoschek/update-playwright
branch
from
c358590
to
1ce299e
Compare
|
Thank you! I just rebased to latest master |
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.
What it does
Update
playwrightto the latest version (and open up version range) as there was a breaking change regarding playwright's Page object.Signed-off-by: Nina Doschek [email protected]
Remark: There is currently one flaky test case, see also #12063.
How to test
test:playwrightReview checklist
Reminder for reviewers