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

tracing integration (#213) #258

Merged
merged 39 commits into from
Mar 3, 2023
Merged

tracing integration (#213) #258

merged 39 commits into from
Mar 3, 2023

Conversation

ilslv
Copy link
Member

@ilslv ilslv commented Feb 21, 2023

Synopsis

#213

Solution

Implement tracing integration under tracing feature. Writers integrations will be done in separate PRs.

Checklist

  • Created PR:
    • In draft mode
    • Name contains Draft: prefix
    • Name contains issue reference
    • Has assignee
  • Documentation is updated (if required)
  • Tests are updated (if required)
  • Changes conform code style
  • CHANGELOG entry is added (if required)
  • FCM (final commit message) is posted
    • and approved
  • Review is completed and changes are approved
  • Before merge:
    • Milestone is set
    • PR's name and description are correct and up-to-date
    • Draft: prefix is removed
    • All temporary labels are removed

@ilslv ilslv added enhancement Improvement of existing features or bugfix k::design Related to overall design and/or architecture labels Feb 21, 2023
@ilslv ilslv self-assigned this Feb 21, 2023
@ilslv
Copy link
Member Author

ilslv commented Feb 23, 2023

@tyranron

Current integration looks like this:

23-02-23_13-34-16

Basically we now run each scenario in tracing::Span, intercept traces, lookup in which Scenario it was done, emit event::Scenario::Log and each Writer does it's job. writer::Basic outputs Scenario's logs only when Scenario is outputted to simplify debugging.

The only question remains: what to do with traces that aren't attached to special tracing::Span? This can happen when spawn(async { ... }) is done or logging from background task.
We can:

  1. Ignore them entirely
  2. Emit them all at the end
  3. Duplicate for each running Scenario with event::Scenario::Log and special flag.
  4. Emit event::Cucumber::Log (not event::Scenario::Log) and let the Writer decide.

Strangely enough, but I would go with option number 3, as it gives the most flexibility. And each Writer can decide on their own, whether to write or skip those traces.

@ilslv
Copy link
Member Author

ilslv commented Feb 24, 2023

@tyranron

Strangely enough, but I would go with option number 3, as it gives the most flexibility. And each Writer can decide on their own, whether to write or skip those traces.

To illustrate my proposal more, if we change function from

#[given(regex = r"(\d+) secs?")]
#[when(regex = r"(\d+) secs?")]
#[then(expr = "{u64} sec(s)")]
async fn step(world: &mut World, secs: CustomU64) {
    tracing::info!("before waiting {secs}s");
    time::sleep(Duration::from_secs(*secs) / 2).await;
    tracing::info!("in between waiting {secs}s");
    time::sleep(Duration::from_secs(*secs) / 2).await;
    tracing::info!("after waiting {secs}s");

    world.0 += 1;
    assert!(world.0 < 4, "Too much!");
}

to

#[given(regex = r"(\d+) secs?")]
#[when(regex = r"(\d+) secs?")]
#[then(expr = "{u64} sec(s)")]
async fn step(world: &mut World, secs: CustomU64) {
    tracing::info!("before waiting {secs}s");
    time::sleep(Duration::from_secs(*secs) / 2).await;
    // Not attached to current `Span`.
    tokio::spawn(async move {
        tracing::info!("in between waiting {secs}s");
    });
    time::sleep(Duration::from_secs(*secs) / 2).await;
    tracing::info!("after waiting {secs}s");

    world.0 += 1;
    assert!(world.0 < 4, "Too much!");
}

We'll get following output:

23-02-24_14-15-42

For @serial Scenarios everything is the same except for missing scenario Span in output, but for concurrently run Scenarios we see all in between waiting ... messages.

@tyranron
Copy link
Member

@ilslv yes, I agree that the option 3 seems to be the most reasonable in this case.

@tyranron
Copy link
Member

tyranron commented Feb 27, 2023

@ilslv also, is it possible to reasonable feature-gate this tracing integration? I believe most of the time people won't need it, so we can avoid increasing compilations times redundantly.

@ilslv ilslv added this to the 0.20.0 milestone Mar 1, 2023
@ilslv
Copy link
Member Author

ilslv commented Mar 1, 2023

FCM

Implement `tracing` crate integration (#258, #213)

- add `tracing` Cargo feature
- add `Log` variant to `event::Scenario`
- describe "`tracing` integration" Book chapter

@ilslv ilslv marked this pull request as ready for review March 1, 2023 10:06
@ilslv ilslv requested a review from tyranron March 1, 2023 10:06
@ilslv ilslv changed the title Draft: tracing integration (#213) tracing integration (#213) Mar 1, 2023
Copy link
Member

@tyranron tyranron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilslv mostly OK, but some minor stuff still to be polished.

src/future.rs Show resolved Hide resolved
src/writer/libtest.rs Show resolved Hide resolved
book/src/output/tracing.md Show resolved Hide resolved
book/src/SUMMARY.md Show resolved Hide resolved
@tyranron tyranron added feature New feature or request k::UI/UX UI (user interface) and UX (user experience) changes semver::breaking Represents breaking changes k::logging Related to library and user logs and removed enhancement Improvement of existing features or bugfix k::design Related to overall design and/or architecture labels Mar 2, 2023
@tyranron
Copy link
Member

tyranron commented Mar 2, 2023

I also dislike the monstrocity happening in runner/basic.rs. It has grown too much. But that's the topic for a different PR in different times.

@tyranron tyranron merged commit a091bb2 into main Mar 3, 2023
@tyranron tyranron deleted the 213-tracing-integration branch March 3, 2023 16:09
@tyranron tyranron linked an issue Mar 3, 2023 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request k::logging Related to library and user logs k::UI/UX UI (user interface) and UX (user experience) changes semver::breaking Represents breaking changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

tracing integration
2 participants