Replies: 1 comment 2 replies
-
|
@digorithm @arboleya @camsjams @Dhaiwat10 @Torres-ssf @danielbate @segfault-magnet @MujkicA @hal3e @Salka1988 @iqdecay @Br1ght0ne @Voxelot Please add your thoughts and add anybody else that you think could contribute. Also, if this is not the appropriate repo for this discussion, please let me know so that I can move it. |
Beta Was this translation helpful? Give feedback.
-
|
@nedsalk I like the general idea of automating these compatibility checks, but unfortunately this might not be that practical for us. From my personal experience dealing with any major |
Beta Was this translation helpful? Give feedback.
-
|
@Dhaiwat10 I agree. |
Beta Was this translation helpful? Give feedback.
-
Recently the TS SDK team went through a cumbersome period aligning the code with fuel-core 0.18.1 and forc 0.40.1. (#986).
It would be great if we could have "compatibility" workflows triggered on every update of the master branches of these packages.
These workflows would pull the latest nightly build of the packages into our SDKs and run all of the tests. If all pass - yay, we're compatible. If they don't pass, we can analyze the causes, check with the respective teams, etc.
I've found a thread where somebody already asked something similar: https://github.com/orgs/community/discussions/26323. From what it looks like, this comment is what we're looking for.
Unfortunately, I did not find a way to simply subscribe to events of another repository and trigger workflows based off of them. That would be the best solution, because there wouldn't be a need to change fuel-core and forc workflows at all.
Thus, the necessary changes, whatever they happen to be, would have to be made both on the fuel-core and forc workflows side and the SDK side.
Whatever comes out of this discussion can possibly be used as a template across the whole organization to ensure compatibility with the latest package versions is met.
Beta Was this translation helpful? Give feedback.
All reactions