Skip to content
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

workflow/e2e: only run experimental daemon #5863

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Benehiko
Copy link
Member

@Benehiko Benehiko commented Feb 24, 2025

- What I did

Only run the daemon in experimental mode for E2E tests.

Closes #5140

- How I did it

- How to verify it

- Human readable description for the release notes

- A picture of a cute animal (not mandatory but encouraged)

@codecov-commenter
Copy link

codecov-commenter commented Feb 24, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 59.27%. Comparing base (656523e) to head (9655637).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #5863   +/-   ##
=======================================
  Coverage   59.27%   59.27%           
=======================================
  Files         353      353           
  Lines       29694    29694           
=======================================
  Hits        17601    17601           
  Misses      11113    11113           
  Partials      980      980           

@Benehiko Benehiko force-pushed the only-experimental-workflow branch from bed1202 to 9655637 Compare February 24, 2025 14:43
@Benehiko
Copy link
Member Author

I could cleanup the scripts to always run with an experimental flag or we could keep them there in case we want to have a split between experimental and normal runs? Instead of removing the non-experimental target from the GitHub workflow, I kept it instead but commented out.

@Benehiko Benehiko self-assigned this Feb 24, 2025
@thaJeztah
Copy link
Member

For the daemon, I think we won't be adding new features gated behind experimental - we largely came to the conclusion that a single "experimental" flags was too much of a big-hammer, and instead we now started to put individual options behind options in features (in daemon.json) where we don't want them to be enabled by default. In all cases (including existing ones), experimental options were adding to existing options, so they would always be a superset of what's tested without experimental. From that perspective, I think it's fine if we just have a single option, enable experimental by default in our tests, and remove distinction between "experimental" and "non-experimental".

For tests that test specific experimental features, we should keep the t.Skip though, but those skips should be based on what the daemon returns (i.e., if the daemon indicates it has experimental disabled, then skip the test).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CI: remove "experimental" checks, as they may be redundant
3 participants