b-reyes

@leewujung and myself just discussed a possible solution to this. The first change we want to make is that `combine_echodata` has a required input, say `output_path` that says where the...

> Seems like we are ready to close this? @b-reyes @lsetiawan I believe the recent fixes to `combine_echodata` address this issue.

> It should be straight forward to use regex instead of split to handle that string parsing. I am curious why the tests didn't have this problem before though --...

> That explains it! But that means we need to fix from the GH actions end. Yes, I agree. The best solution would be to make the GH actions install...

> Did you mean locally run tests? Also, can you specify which tests specifically are failing? @emiliom all PR CI tests should work properly. Locally, everything should be fine too...

> It's pretty odd that the same context leads to test failures in the build GH actions but not in the PR GH actions. I agree. On the bright side,...

> > I definitely agree that we should be using the descriptions within the set groups instead of 1.0.yml since that is what is being used in set groups. Maybe...

> Exactly. I added this _beamgroups property to address the decision we made to have sensor-customized beam group descriptions. The intent is that this property should be used directly wherever...

> Or come to think of it, maybe no change is needed? The echodata repr operates on an echodata object, so the _beamgroups property is easily accessible to the repr...

> Quick reply: > > * All the `sonar_*` attributes are defined as such by the convention. For EK80, based on what I've seen, I assume @leewujung found it necessary...