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

fix: update logic to check for available ios devices for log-ios to work #1675

Conversation

esthor
Copy link
Contributor

@esthor esthor commented Aug 12, 2022

Summary:

Hey, just ran into this while working on a new feature.

When pulling the devices via xcrun simctl list devices --json now, I don't actually get the availability key, I just get the isAvailable key. They are both already listed as optional keys in the Device type in the repo. My guess is that the availability key was on an older version of simctl.

Anyway, if I run the log-ios as-is, without this change, it always fails to find an available iOS device because device.availability simply never exists. Changing it to also check for device.isAvailable works.

Test Plan:

environment:
macOS 12.5 (latest stable)
xcrun version 61 / xcode 13.4.1 (latest stable)

  1. Have an iOS simulator open and running
  2. Run the log-ios command as is in the current main cli branch. (Result: FAILS with error: No active iOS device found)
  3. Run the log-ios command with this PR's code. (Result: Successfully finds the active simulator and starts a log session)

@esthor
Copy link
Contributor Author

esthor commented Aug 12, 2022

Two things that we might want to follow-up on:

  1. update tests (the findMatchingSimulator.test.ts still just passes device.availability mocks, so it should probably have some mocks with device.isAvailable)
  2. make a shared variable for availability so we don't repeat ourselves in the future and can update the logic in just one place?

(please lmk if these are needed before merging or anything else)

Copy link
Member

@thymikee thymikee left a comment

Choose a reason for hiding this comment

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

Thanks!

@thymikee
Copy link
Member

It looks like we have some overlapping implementations, and this is properly resolved in run-ios, but it haven't propagated to log-ios:

simulator.availability !== '(available)' &&
// @ts-ignore verify isAvailable parameter
simulator.isAvailable !== 'YES' &&
simulator.isAvailable !== true

Would you be so kind and refactor this so more code is being shared, to avoid such discrepancies in the future?

@thymikee thymikee self-requested a review August 17, 2022 19:33
(device.availability === '(available)' ||
device.isAvailable === true) &&
device.state === 'Booted'
) {
Copy link
Collaborator

@adamTrz adamTrz Aug 18, 2022

Choose a reason for hiding this comment

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

Hi @esthor thanks for the fix! 💪
Question - is there a chance that device is "Booted" and not available? 🤔
If not then I think this logic could be simplified a bit and we won't care anymore about availability v isAvailable mismatch :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think you're probably right in this case. Will have to double-check, but it doesn't really make sense to be unavailable but Booted for a simulator, but similar logic was there before. Maybe there is an edge case 🤷

@esthor
Copy link
Contributor Author

esthor commented Aug 22, 2022

Would you be so kind and refactor this so more code is being shared, to avoid such discrepancies in the future?

Yes, 💯 . I wanted to propose this, but didn't want to risk rocking the boat too much. Happy to hop on it!

@adamTrz
Copy link
Collaborator

adamTrz commented Aug 25, 2022

Would you be so kind and refactor this so more code is being shared, to avoid such discrepancies in the future?

Yes, 💯 . I wanted to propose this, but didn't want to risk rocking the boat too much. Happy to hop on it!

Go for it! 💪

@esthor
Copy link
Contributor Author

esthor commented Sep 12, 2022

Would you be so kind and refactor this so more code is being shared, to avoid such discrepancies in the future?

Yes, 💯 . I wanted to propose this, but didn't want to risk rocking the boat too much. Happy to hop on it!

Go for it! 💪

Will do!

@thymikee
Copy link
Member

@esthor is there anything we can help you with to push this through?

@esthor
Copy link
Contributor Author

esthor commented Nov 13, 2022

I'm adding it to my TODO in a week 🙏

@github-actions
Copy link

There hasn't been any activity on this pull request in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

@github-actions github-actions bot added the stale label Feb 12, 2023
@esthor
Copy link
Contributor Author

esthor commented Feb 14, 2023

My bad, I thought this was handled in other changes, but it's not. I'll find some time to try and wrap up this PR.

@github-actions github-actions bot removed the stale label Feb 15, 2023
@szymonrybczak
Copy link
Collaborator

Hey @esthor, recently @adamTrz fixed error with getting devices and simulators in CLI #1823 and basically there was a change from xcrun xctrace list devices to xcrun xcdevice list --json, and this new command outputs the beautiful JSON with all required informations together with avaliable. We're thinking about moving to this new command also in log-ios . Because it's safer (we're not doing some crazy regex, and after that tons of difficult logic instead we're just getting information from JSON).

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.

4 participants