ci: trigger status-app build - #7480
Conversation
|
Jenkins BuildsClick to see older builds (44)
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #7480 +/- ##
========================================
Coverage 62.30% 62.30%
========================================
Files 868 868
Lines 120155 120155
========================================
+ Hits 74858 74868 +10
+ Misses 37662 37623 -39
- Partials 7635 7664 +29
Flags with carried forward coverage won't be shown. Click here to find out more. |
2325a7c to
ab2a47d
Compare
ab2a47d to
818a49b
Compare
818a49b to
69a1222
Compare
alexjba
left a comment
There was a problem hiding this comment.
Not sure how it would work. E.g. Changing a signature in status-go requires nim-statusgo update, statusapp bump + some code alignments.
I see the status-app companion PR most useful for quick testing - reviewers and QA can grab the build and do a quick check on it. So I'm not sure a status-app compilation job is a good replacement.
|
@alexjba : The point here is that the companion PR forced a dev to perform a task which this job automates.
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 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. |
jrainville
left a comment
There was a problem hiding this comment.
This fixes #7667
I guess it will be up to us to enforce companion PRs in the case where APIs are changed, because then running the e2e suite would be good too.
but similar to the nim-status-go bindings, we cannot test it easily
|
@alexjba: To make things easier I made status-im/status-app#21746 to bring in @jrainville: I can run status-app E2E after status-app client builds are done here itself, so that would reduce friction? |
c6c4837 to
4e03335
Compare
The hell does that even mean? |
4e03335 to
9d88dc1
Compare
The new job would fail on a change like this because status-app expects a different signature for |
|
Hmm fair enough, currently this job builds Then the signature changes could be made in |
Yes |
5316977 to
4b7d327
Compare

Summary