| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
When the daemon transitions directly from error to disconnected
(skipping disconnecting), the predicted disconnecting UI state was not
cleared immediately, leaving the GUI stuck for up to 3 seconds.
Accept any real tunnel state as replacing the predicted state so the UI
updates immediately.
|
|
|
|
|
|
This fixes a crash for WMIConnection used in a thread-local context
Co-authored-by: Markus Pettersson <markus.pettersson@mullvad.net>
|
|
|
|
The path was updated in #10242
|
|
|
|
|
|
|
|
Upgrading AGP to 9.1.1 picked up a new CVE, it has no impact on the app
but is part of the buildchain.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The daemon sends multiple consecutive 'connected' tunnel state events
(first without exit IP, then with IP from am.i.mullvad.net), which
caused duplicate "Connected to ..." notifications to appear.
|
|
'if-user-has-no-time-left-the-app-will-send-reminders-over-droid-2639'
|
|
|
|
|
|
According to [this documentation][1], I should've written `success`
instead of `successful`, and this is also double-checked by querying the
API:
```sh
curl -SsfL -H @headers $GITHUB_API | jq '{ state, conclusion }'
{
"state": null,
"conclusion": "success"
}
```
[1]: https://archive.is/4IM5j#check-statuses-and-conclusions
|
|
After testing and observing, we'll now use the `workflow_run` method
of observing a workflow's result to trigger failure notifications
when needed.
**Impact**: Right now we receive a **duplicate** notification if the
nightly run fails due to failing tests (as described in
9d89d7316104b2cbd158f78d94bdf824d2274d69). Removing this delegates
the notification responsibility entirely to the
`ios-end-to-end-nightly-monitor`-workflow, which also offers
observability when the run is cancelled, amongst [other][1] possible
reasons.
[1]: https://archive.is/4IM5j#check-statuses-and-conclusions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update base Dockerfile to remove Golang, since all app version built by
this container no longer depend on wireguard-go.
|
|
|
|
This commit introduces a notification on any case of a `completed` but
unsuccessful workflow (i.e. where the conclusion is not `success`).
**Rationale**: We currently send a notification if the E2E tests run
and fail. Due to runner issues some scheduled nightly runs never get
executed. As we only get notified of failing runs, we assume that
"No news is good news", but that is not necessarily true.
According to [this GitHub documentation][1]
we should be able to monitor whether the iOS E2E test workflow is
completed, which fits wanting to be informed about _both_ failed tests
and scheduled runs, regardless of the reason.
**How to test**: ~We should be able to execute the workflow using this
PR/branch.~ According to the [documentation][2] this will only run on
the `default` branch:
> This event will only trigger a workflow run if the workflow file
> exists on the default branch.
**Technical details**:
- [Workflow_run][3]
has 3 `action types`: `requested`, `in_progress` and `completed`.
- The `workflow_run` payload is documented [here][4].
**Note**: As I did not delete the original notification in
`ios-end-to-end-tests-nightly.yml`, failed runs will notify us twice
right now. I'd propose to remove that notification _after_ we've
observed this notification to work consistently.
**Caveat**: I did come across
https://github.com/orgs/community/discussions/21090, but given the
amount of time that has passed, I'm curious to see if that issue has
been resolved in the meantime.
[1]: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#running-a-workflow-based-on-the-conclusion-of-another-workflow
[2]: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_run
[3]: https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=completed#workflow_run
[4]: https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2026-03-10#get-a-workflow-run
|
|
|
|
|
|
Reading from mullvad-exclude's `cgroup.procs` immediately after
moving a process to its parent causes it to be moved back to the
mullvad-exclude cgroup. This causes 'mullvad split-tunnel clear' to
never complete.
|
|
|
|
|
|
|
|
|
|
This is done the same way as for the other builds
in the Android reproducible builds workflow.
|
