Goal is to help developers and project leads/issue triagers
We have ~200 repos with lots of little differences
A repo check is something to ensure is true about a repository
repo_checks command line tools lets you execute checks as dry runs or as active fixes
Right now Axim runs it, but anyone can submit a PR and #ask-axim for review
Recent check: Ensure Labels
labels are inconsistent between repositories (“bug ” vs “bug” vs “ bug”)
goals is to have a consistent set of labels/colors, loaded from a labels.yaml file in the repo-tools repo
Q: How does this compare with Repo Health Checks (used by 2u)?
A: @Feanil Patel knows more. There is definitely more emphasis in repo_checks on fixing the inconsistencies rather than just reporting them. Repo health dashboard data is also currently not visible outside 2u. There’s also some crossover with backstage.
Atlassian’s version of Backstage + Okay (development metrics)
In free beta
Don’t have it turned on yet, so not a lot more to say beyond that it looks like it could solve some of 2U’s problems if it works as advertised
Still nailing down issues with Apple Silicon and local development around MFEs.
2U is still focused on devstack work and fixes vs. Tutor.
@Brian Smith is continuing to work on tutor-mfe support for running MFEs on the host (devstack style). Current challenge is around mismatched host names (localhost:xxxx vs apps.local.overhang.io:xxxx). He’s looking into a couple solutions/workarounds there.
If you have an idea for follow up actions, add it.
Or if you aren’t sure, leave it blank.
We’ll discuss all actions either way.
@Rebecca Graber - devstack whackamole. Some issues are reproducible, some less so, some are only reproducible in certain contexts, and everyone seems to be using their own set of documentation
I am getting an M1 so hopefully that will help compare things between intel and silicon
much of it is edx-platform as much as devstack but it’s often hard to tell
@Kyle McCormick Devstack dissuades removal of containers (dev.remove-containers, formerly dev.down) which is usually a performance win, but container removal is an important part of isolating issues and is still much better than a full destroy.
Possible documentation update: reminding people to remove-containers before destroying as a step in troubleshooting