diff --git a/.github/workflows/deploy-adr-docs.yml b/.github/workflows/deploy-adr-docs.yml new file mode 100644 index 00000000000..111838e3ff0 --- /dev/null +++ b/.github/workflows/deploy-adr-docs.yml @@ -0,0 +1,48 @@ +name: Deploy ADR Docs + +on: + push: + branches: [ 'develop', 'chore/adr-and-tests' ] + pull_request: + types: [ opened, synchronize ] + paths: [ 'docs/adr/**' ] + +permissions: + contents: write + pull-requests: write + +env: + GITHUB_TOKEN: ${{ secrets.ANDROID_BOB_GH_TOKEN }} + +jobs: + publish: + runs-on: ubuntu-latest + steps: + - name: Checkout project + uses: actions/checkout@v4 + + - name: Install pip for adr-viewer + run: | + sudo apt-get update + sudo apt-get install -y python3-pip + pip install adr-viewer + + - name: Generate ADR docs + run: | + adr-viewer --adr-path docs/adr --output docs/index.html + + - name: Deploy docs 🚀 + if: github.event_name == 'push' && github.ref_name == 'develop' + uses: JamesIves/github-pages-deploy-action@v4.6.3 + with: + branch: gh-pages + clean: false + folder: docs + target-folder: docs + + - name: Comment new ADR(s) in PR + if: github.event.pull_request.head.repo.full_name == github.repository && github.event_name == 'pull_request' + run: | + echo "# New ADR(s) in this PR 📚:" > /tmp/new-adr + gh pr diff ${{ github.event.pull_request.number }} --name-only | grep docs/adr | xargs cat >> /tmp/new-adr + gh pr comment ${{ github.event.pull_request.number }} -F /tmp/new-adr --edit-last || gh pr comment ${{ github.event.pull_request.number }} -F /tmp/new-adr diff --git a/app/src/test/kotlin/com/wire/android/ui/userprofile/common/UsernameMapperTest.kt b/app/src/test/kotlin/com/wire/android/ui/userprofile/common/UsernameMapperTest.kt new file mode 100644 index 00000000000..4904afd7a16 --- /dev/null +++ b/app/src/test/kotlin/com/wire/android/ui/userprofile/common/UsernameMapperTest.kt @@ -0,0 +1,26 @@ +package com.wire.android.ui.userprofile.common + +import com.wire.android.framework.TestUser.OTHER_USER +import com.wire.kalium.logic.data.user.OtherUser +import com.wire.kalium.logic.data.user.type.UserType +import org.junit.jupiter.api.Assertions.assertEquals +import org.junit.jupiter.params.ParameterizedTest +import org.junit.jupiter.params.provider.EnumSource + +class UsernameMapperTest { + + @ParameterizedTest + @EnumSource(TestParams::class) + fun `should map other user to its username - handle accordingly`(params: TestParams) { + assertEquals(params.expected, UsernameMapper.fromOtherUser(params.input), "Failed for input: <${params.input}>") + } + + companion object { + + enum class TestParams(val input: OtherUser, val expected: String) { + FEDERATED_USER(OTHER_USER.copy(userType = UserType.FEDERATED, handle = "handle"), "handle@domain"), + REGULAR_USER(OTHER_USER.copy(userType = UserType.GUEST, handle = "handle"), "handle"), + NO_HANDLE_USER(OTHER_USER.copy(userType = UserType.INTERNAL, handle = null), "") + } + } +} diff --git a/docs/adr/0000-template-lightway-adr.md b/docs/adr/0000-template-lightway-adr.md new file mode 100644 index 00000000000..c17fe0272e4 --- /dev/null +++ b/docs/adr/0000-template-lightway-adr.md @@ -0,0 +1,24 @@ +# Decision record template by Michael Nygard + +This is the template in [Documenting architecture decisions - Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions). +You can use [adr-tools](https://github.com/npryce/adr-tools) for managing the ADR files. + +In each ADR file, write these sections: + +# Title + +## Status + +What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.? + +## Context + +What is the issue that we're seeing that is motivating this decision or change? + +## Decision + +What is the change that we're proposing and/or doing? + +## Consequences + +What becomes easier or more difficult to do because of this change? diff --git a/docs/adr/0001-record-architecture-decisions.md b/docs/adr/0001-record-architecture-decisions.md new file mode 100644 index 00000000000..79864160393 --- /dev/null +++ b/docs/adr/0001-record-architecture-decisions.md @@ -0,0 +1,26 @@ +# 1. Record architecture decisions + +Date: 2024-08-05 + +## Status + +Accepted + +## Context + +We agreed in the past to use ADR's, but we lost track of it as we were using confluence to keep +them. This concern was raised in the last collective, and we need to decide how to proceed. + +## Decision + +We will use Architecture Decision Records in the code and as part of the review process. +We will use the [Lightway ADR template](0000-template-lightway-adr.md) to keep the ADRs simple and +easy to maintain. + +## Consequences + +- We need to add a new folder to the repository, `docs/adr`, to keep the architecture decision + records. +- Whenever a new refactoring or library is introduced, a new ADR should be created. +- You can always request in the Pull request review process to add a new ADR, if you think it's + necessary. diff --git a/docs/adr/0002-calling-activities-refactor.md b/docs/adr/0002-calling-activities-refactor.md new file mode 100644 index 00000000000..3f130fed6d3 --- /dev/null +++ b/docs/adr/0002-calling-activities-refactor.md @@ -0,0 +1,31 @@ +# 2. Calling activity refactor + +Date: 2024-08-01 + +## Status + +Accepted + +## Context + +To support a second incoming call we need to refactor the code so we can handle the ongoing content +context, without losing the current context. + +This is a retroactive decision record implemented +on https://github.com/wireapp/wire-android/pull/3264 + +## Decision + +Create 2 separate activities, one for the Incoming/Outgoing calls and another for the ongoing call. +In this way, we can keep the context of the ongoing call and handle the incoming/outgoing calls. + +The design and interaction will look like this: + + + +## Consequences + +- StartingActivity will handle Incoming and Outgoing calls content, these contents are disposable + and can be recreated when receiving a new call. +- OngoingCallActivity will handle the ongoing call content, this content is not disposable and + should be kept during the call. diff --git a/docs/adr/0003-introducing-junit5-parametrizable-tests.md b/docs/adr/0003-introducing-junit5-parametrizable-tests.md new file mode 100644 index 00000000000..03281515734 --- /dev/null +++ b/docs/adr/0003-introducing-junit5-parametrizable-tests.md @@ -0,0 +1,21 @@ +# 3. Use parameterizable tests in JUnit5 + +Date: 2024-08-05 + +## Status + +Proposed + +## Context + +Sometimes we need to write multiple tests for the same scenario, changing only the input values. + +## Decision + +We will use parameterizable tests in JUnit5 to avoid writing multiple tests for the same scenario. + +## Consequences + +- Introduction of `@ParameterizedTest` annotation in the test class + and [library](https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests). +- The test method will receive the parameters as arguments.