Closed
Conversation
This was referenced Mar 28, 2025
Closed
Closed
Codecov ReportAll modified and coverable lines are covered by tests ✅ 🚀 New features to boost your workflow:
|
6 tasks
Collaborator
|
closed by #163 |
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
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.
Pull Request Overview
This pull request tracks all outstanding PRs regarding to the testsuite rework, their purpose, and other relevant information.
Overview of mentioned PRs (so you can see their names also)
RwLockand concurrency enabledLinearMemory#136Motivation
A bug within the testsuite runner was detected not so long ago in PR #136 . Some direct
invokedirective caused the testsuite runner to crash due to an uncaught panic in the handling of those directives. This was a double-edged sword. Firstly, it indicated a bug in the implementation, however the panic should have been caught and reported by the runner (and thus the PR should not have failed but we would also not notice the error).This is a tricky approach. On one hand, we want to see all possible bugs caught by the testsuite, but on the other hand we have so many non-working tests that it is close to impossible to determine which are caused by features not being yet implement and which are determined by a faulty implementation.
A meet-in-the-middle solution would be to report all changes to the testsuite results in a PR. This would catch previously passing
.wastfiles becoming failing or with a script error (previously named compilation error). This would not catch a script error's cause being different1.In this entire process, a rework to the code itself was made.
Relevant PRs
The first relevant PR is #126 . This added the first draft to a github action which would print out the changes.
After some time, the bug in #136 happened, and as a response PR #143.
Afterwards, I decided to rework the code for the testsuite runner to enable more changes (and in general have the code be cleaner). The rework was done in PR #146 and contains the changes in PR #143.
After that, I've reworked the testsuite preview (#126) to take advantage of the rework, and in general made it more robust. There are 2 PRs relevant to this #147 that merges from
george-cosmafork and #149 that merges from this repo. The reasons I mention this is that #147 kept failing to post the comment due to permission issues. This has been fixed, but due to security reasons Github will not run that action without it being first merged into main (or the target branch of the PR, but we usually merge into main)This project might open up for more people in the future, and we want our CI actions to work even if they come from across forks.
What's left to do?
First, the commit history needs to be cleaned up. Unfortunately, testing actions that change PR contents are nearly impossible to test locally. Secondly,
nix flake checkneeds to pass.Thirdly, we might want to change how the difference checker algorithm works if a change in error message is detected. However, I would leave this feature to another PR.
Footnotes
A feature could be implemented to check if the error message is different, at best ↩