-
Notifications
You must be signed in to change notification settings - Fork 28
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
[PM-9375] Build a debug-for-simulator version of the app for easier automated testing #1151
base: main
Are you sure you want to change the base?
Conversation
No New Or Fixed Issues Found |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1151 +/- ##
=======================================
Coverage 89.47% 89.47%
=======================================
Files 688 688
Lines 43811 43811
=======================================
Hits 39202 39202
Misses 4609 4609 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏾
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-9375
📔 Objective
In order to run automated tests without locally downloading Xcode and running the tests manually, the QA folks need a debug build that can be downloaded and installed on an arbitrary simulator. This flow produces this build as part of the standard CI flow, along with adding a workflow that can be called separately.
I debated between making this a separate flow (and script) instead of just using the current
build.yml
, but ultimately I felt like the differences between them were too great. There are a lot of steps that don't need to happen for a simulator build, and thexcodebuild
invocation is sufficiently different that it seemed reasonable to keep it separate. I also thought it was more likely that we would potentially pull this invocation out of theCI main
workflow and set up an alternate set of triggers for it, depending on QA's needs, and having a separately invocable action makes that easier. However, at some point in the future that calculus might change and it might make more sense to merge this with thebuild.yml
workflow.There are also some minor touch-ups to the
build.sh
script: removing dead code, fixing a capitalization error, and adding more explicit logging.⏰ Reminders before review
🦮 Reviewer guidelines
:+1:
) or similar for great changes:memo:
) or ℹ️ (:information_source:
) for notes or general info:question:
) for questions:thinking:
) or 💭 (:thought_balloon:
) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:
) for suggestions / improvements:x:
) or:warning:
) for more significant problems or concerns needing attention:seedling:
) or ♻️ (:recycle:
) for future improvements or indications of technical debt:pick:
) for minor or nitpick changes