Skip to content
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.

GHA: make element-web and cypress workflows reusable #10969

Merged
merged 5 commits into from
May 26, 2023

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented May 23, 2023

Part of element-hq/element-web#25313.

The idea here is to allow us to fire off a Cypress test run against a rust-crypto-enabled Element Web R after each js-sdk PR. These need to run in the context of a js-sdk PR, so we could just copy-paste the workflows into the js-sdk; however a more pleasant alternative is to make the existing workflows re-usable.


This change is marked as an internal change (Task), so will not be included in the changelog.

@richvdh richvdh requested a review from a team as a code owner May 23, 2023 13:27
@richvdh richvdh requested a review from germain-gg May 23, 2023 13:28
@richvdh richvdh added the T-Task Refactoring, enabling or disabling functionality, other engineering tasks label May 23, 2023
@t3chguy t3chguy requested review from t3chguy and removed request for germain-gg May 23, 2023 13:29
@richvdh richvdh marked this pull request as draft May 24, 2023 14:49
@richvdh richvdh changed the title GHA: allow triggering a build with custom js-sdk and rust crypto GHA: make element-web and cypress workflows reusable May 25, 2023
Comment on lines +15 to +18
react-sdk-repository:
type: string
required: true
description: "The name of the github repository to check out and build."
Copy link
Member

Choose a reason for hiding this comment

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

Surely this could be driven by just choosing that repository to workflow_call an action upon?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, I don't understand?

Copy link
Member Author

Choose a reason for hiding this comment

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

To be clear: I don't believe there is any way to figure out which repo this workflow file has been sourced from, from within the workflow.

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

we've discussed this at some length in the chat, but to summarise my position:

One way or the other, we have to hardcode matrix-org/matrix-react-sdk twice. We can either:

  • Put it in the calling workflow twice (as matrix-js-sdk#3412 does), or:
  • Put it once in the calling workflow, and once in the target workflow.

There are a couple of approaches to the latter, but whichever approach we take, my contention is that, given the need for duplication, it's better that the duplicates be next to each other than at a distance. Primarily, doing so makes it much clearer what needs to be changed when setting up a fork.


Looking at this from the PoV of the calling workflow, we either have:

  1. @t3chguy's proposal:

    jobs:
      build-element-web:
        uses: matrix-org/matrix-react-sdk/.github/workflows/element-web.yaml@HEAD
        with:
          matrix-js-sdk-sha: ${{ github.sha }}

    It is unclear to me, looking at that incantation, that even if I change the reference in uses, it will still build the react-sdk from matrix-org/matrix-react-sdk.

  2. @richvdh's proposal:

    jobs:
      build-element-web:
        uses: matrix-org/matrix-react-sdk/.github/workflows/element-web.yaml@HEAD
        with:
          matrix-js-sdk-sha: ${{ github.sha }}
          react-sdk-repository: matrix-org/matrix-react-sdk

    Yes there is duplication there, but it saves hardcoding the repository in the target workflow, and it is pretty obvious what I need to change if I want to use a fork of the react-sdk.

Copy link
Member

Choose a reason for hiding this comment

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

a third approach is to split out into a composite action which the js-sdk and other callers can call, and it'll have access to its own repository via github.action_repository where no duplication or hard-coding is needed

Comment on lines +19 to +22
react-sdk-repository:
type: string
required: true
description: "The name of the github repository to check out and build."
Copy link
Member

Choose a reason for hiding this comment

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

Same as above

.github/workflows/element-web.yaml Outdated Show resolved Hide resolved
.github/workflows/cypress.yaml Outdated Show resolved Hide resolved
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
Copy link
Contributor

@andybalaam andybalaam left a comment

Choose a reason for hiding this comment

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

The repetition Rich proposes looks almost 100% harmless, and the code looks good otherwise.

@richvdh richvdh added this pull request to the merge queue May 26, 2023
Merged via the queue into develop with commit 3bba816 May 26, 2023
@richvdh richvdh deleted the rav/actions_hacking/1 branch May 26, 2023 15:30
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T-Task Refactoring, enabling or disabling functionality, other engineering tasks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants