Closed deusebio closed 1 year ago
Should we make the test repository be in the canonical org?
It would be great if we can include some documentation on how to execute the new e2e tests and what the new branching strategy is (e.g., merge to edge
first, run the e2e tests then merge to main or something like that
Should we make the test repository be in the canonical org?
Yes. Let's address the PR and I will then create a brand new repository (I don't think the history we have there is very relevant)
Test coverage for 187d047219bf31aa505cd3c2e7291e4aa9bc2805
Name Stmts Miss Branch BrPart Cover Missing
---------------------------------------------------------------------
src/__init__.py 71 0 28 0 100%
src/action.py 154 0 46 0 100%
src/check.py 53 0 21 0 100%
src/clients.py 12 0 0 0 100%
src/commit.py 42 0 12 0 100%
src/constants.py 9 0 0 0 100%
src/content.py 50 0 10 0 100%
src/discourse.py 156 0 34 0 100%
src/docs_directory.py 33 0 8 0 100%
src/download.py 23 0 2 0 100%
src/exceptions.py 15 0 0 0 100%
src/index.py 128 0 48 0 100%
src/metadata.py 28 0 12 0 100%
src/migration.py 87 0 27 0 100%
src/navigation_table.py 65 0 20 0 100%
src/reconcile.py 87 0 38 0 100%
src/repository.py 282 0 88 0 100%
src/sort.py 39 0 22 0 100%
src/types_.py 147 0 22 0 100%
---------------------------------------------------------------------
TOTAL 1481 0 438 0 100%
Static code analysis report
Working... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:01
Run started:2023-08-24 15:21:45.880536
Test results:
No issues identified.
Code scanned:
Total lines of code: 15407
Total lines skipped (#nosec): 14
Total potential issues skipped due to specifically being disabled (e.g., #nosec BXXX): 0
Run metrics:
Total issues (by severity):
Undefined: 0
Low: 0
Medium: 0
High: 0
Total issues (by confidence):
Undefined: 0
Low: 0
Medium: 0
High: 0
Files skipped (0):
In this PR, we remove the End-2-End tests from the current repository, and moved them to a Test repository, here. The reason for this was:
The idea discussed with @jdkandersson was to export the E2E tests into a separate repository. Of course this exposes us to the risk of merging features that are not working (altough pass unit and integration tests). The idea here would be to have edge and stable branches in this repository. Scheduled E2E tests workflow run against an edge branch in this repository, whereas actions in production should use stable branches. Promoting edge to stable should be a manual process done once we are comfortable a certain revision is good enough.
Tasks
I have now migrated most of the relevant code and business logic about end-to-end testing in the test repository, and I have also extended them to include raising PR and a conflict workflow (only hard conflict so far since the soft ones may go deprecated). This refactoring has however had impacts on this repository as
There is a PR which shows some meaningful diff, on how that was achieved, alongside the tests workflow (against the branch of this PR), here and here. The code in the PR can have several improvements, but I believe it would be more critical to get the end-to-end tests up and running.