Skip to content

feat(codecov): Add onboarding radio selector for GHA or CLI #90980

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

Merged
merged 4 commits into from
May 21, 2025

Conversation

calvin-codecov
Copy link
Contributor

@calvin-codecov calvin-codecov requested a review from a team as a code owner May 5, 2025 23:30
@github-actions github-actions bot added the Scope: Frontend Automatically applied to PRs that change frontend components label May 5, 2025
@calvin-codecov calvin-codecov force-pushed the cy/codecov_onboarding_radio branch from 03da34c to fa12f3f Compare May 12, 2025 18:33
Copy link

codecov bot commented May 12, 2025

❌ 1 Tests Failed:

Tests completed Failed Passed Skipped
10311 1 10310 9
View the top 1 failed test(s) by shortest run time
EventSearch handles basic inputs for tags
Stack Traces | 5.08s run time
Error: thrown: "Exceeded timeout of 5000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
    at .../issueDetails/streamline/eventSearch.spec.tsx:51:3
    at _dispatchDescribe (.../jest-circus/build/index.js:91:26)
    at describe (.../jest-circus/build/index.js:55:5)
    at Object.<anonymous> (.../issueDetails/streamline/eventSearch.spec.tsx:15:1)
    at Runtime._execModule (.../jest-runtime/build/index.js:1439:24)
    at Runtime._loadModule (.../jest-runtime/build/index.js:1022:12)
    at Runtime.requireModule (.../jest-runtime/build/index.js:882:12)
    at jestAdapter (.../build/legacy-code-todo-rewrite/jestAdapter.js:77:13)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at runTestInternal (.../jest-runner/build/runTest.js:367:16)
    at runTest (.../jest-runner/build/runTest.js:444:34)
    at Object.worker (.../jest-runner/build/testWorker.js:106:12)

To view more test analytics, go to the Test Analytics Dashboard
📋 Got 3 mins? Take this short survey to help us improve Test Analytics.

)}
</TAValueText>
</IntroContainer>
<SelectOptionHeader>Select a setup option</SelectOptionHeader>
Copy link
Contributor

Choose a reason for hiding this comment

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

t()


export default function TestsOnboardingPage() {
const [searchParams, setSearchParams] = useSearchParams();
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm curious as to why we're using the url to handle state vs a local useState. Are we expecting to reach the /new route with a url param that could be any of these two? And what is the value of exposing the opt to the customer via the URL vs having it in an internal state?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm...I swear I read somewhere that a requirement was to have the url change so that linking to it would preset the option. Now I'm having a hard time finding where I saw that though... Gonna have to do a little bit of digging

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ahh, it was on this ticket https://linear.app/getsentry/issue/CCMRG-150/test-analytics-onboarding-create-radio-selection. Seems like we may have two similar/duplicate tickets for the radio selector that were created at different times. This is the other one I have included in the PR description https://linear.app/getsentry/issue/CCMRG-426/add-radio-selector-for-choosing-between-gh-actions-and-cli

Copy link
Contributor

Choose a reason for hiding this comment

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

Ahh gotcha gotcha, ok sounds good! Yeap if this is expected to be part of the URL then this approach is good.

Should the url be populated with the default value if one isn't provided?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you see any benefits we would get with the default value being added? I was thinking of setting the searchParams on mount to add the query param by default but that forces a remount which I think may not be worth it if it already works when no default is specified.

Copy link
Contributor

Choose a reason for hiding this comment

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

Mostly it being in sync with the app's state. When you click on another entry it syncs, which is nice, but I suppose if you default to an option it's okay as long as there's a default for blank.

initialRouterConfig: {
location: {
pathname: '/codecov/tests/new',
query: {opt: ''},
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it'd be worth adding a test with query being empty/null; subtle but different is that the radio button will have the default value (gha) but the opt will be '' (or undefined if it's just /new), leaving the url and button out of sync. Sort of tied to my other comment of having the url be the state vs a useState hook

@calvin-codecov calvin-codecov force-pushed the cy/codecov_onboarding_radio branch from 04b47dd to e8695d6 Compare May 21, 2025 18:03
@calvin-codecov calvin-codecov merged commit ba7bc8f into master May 21, 2025
41 checks passed
@calvin-codecov calvin-codecov deleted the cy/codecov_onboarding_radio branch May 21, 2025 18:21
@github-actions github-actions bot locked and limited conversation to collaborators Jun 6, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Scope: Frontend Automatically applied to PRs that change frontend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants