ci: trigger status-app build - #7480

⚠️ Companion PR Required

Add a link to your status-app PR in this PR's description.

Example: https://github.com/status-im/status-app/pull/123

Jenkins Builds

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.47%. Comparing base (d99d2e1) to head (dc78a0d).

@@             Coverage Diff              @@
##           develop    #7480       +/-   ##
============================================
+ Coverage    42.34%   62.47%   +20.12%     
============================================
  Files          854      870       +16     
  Lines       117865   121044     +3179     
============================================
+ Hits         49911    75621    +25710     
+ Misses       61509    37720    -23789     
- Partials      6445     7703     +1258     

@alexjba : The point here is that the companion PR forced a dev to perform a task which this job automates.
The status-app job will build all client packages with the current version of status-go and catch build failures if any.

QA can still grab artefacts from here and test if they want to.

If change in status-go introduces a build failure in status-app then this job will force a dev to fix the relevant compatibility issue in status-app otherwise devs that do not introduce such changes can just merge their status-go PR without having to worry about opening companion PRs.

@siddarthkay what would be the flow in this case:

I'm changing a signature in status-go. It needs a nim-status-go PR first and then a status-app PR, otherwise status-app will fail to link status-go.

hmm the nim-status-go repo if consumed only by status-app should not be a separate repo.
We didn't have this problem in status-legacy because the bindings or wrapper around status-go lived in status-legacy itself.

In this case the separate repo is complicating the workflow.

true, there's no good reason to keep nim-status-go as a separate repo. Ideally all these bindings would be generated.
But even so, a change in the signature that's not backwards compatible would still get in the way here.

@alexjba: To make things easier I made status-im/status-app#21746 to bring in nim-status-go into status-app
Please review that change, now status-go signature change will only need a status-app PR to test.

@jrainville: I can run status-app E2E after status-app client builds are done here itself, so that would reduce friction?

a change in the signature that's not backwards compatible would still get in the way here

The hell does that even mean?

a change in the signature that's not backwards compatible would still get in the way here

The hell does that even mean?

The new job would fail on a change like this because status-app expects a different signature for Login. Anyways, I don't mean to block this work, just making sure we're all on the same page about enforcing backwards compatibility on status-go since we didn't had it before.

--- a/pkg/backend/geth_backend.go
+++ b/pkg/backend/geth_backend.go
@@ -857,7 +857,7 @@ func (b *StatusBackend) GetEnsUsernames() ([]*ens.UsernameDetail, error) {
        return db.GetEnsUsernames(&removed)
 }
 
-func (b *StatusBackend) Login(keyUID, password string) error {
+func (b *StatusBackend) Login(password string) error {
        return b.startNodeWithAccount(multiaccounts.Account{KeyUID: keyUID}, password, nil, nil)
 }

Hmm fair enough, currently this job builds status-go PR against master of status-app. For such cases it would be beneficial to allow specifying a branch of status-app to build against... to verify compatibility.

Then the signature changes could be made in status-app, that should solve the problem?

Hmm fair enough, currently this job builds status-go PR against master of status-app. For such cases it would be beneficial to allow specifying a branch of status-app to build against... to verify compatibility.

Then the signature changes could be made in status-app, that should solve the problem?

Yes

Thank you for opening this pull request!

We require pull request titles and commits to follow the Conventional Commits specification and it looks like your PR needs to be adjusted.

Details:

According to the conventional-commits specification, some of the commit messages are not valid.

@alexjba : I added the support for building a branch of status-app here : 958aaf5

and this is an example of how to use it : 24f110c