Arch Hour: 2020-11-19
Topics
Frontend organisms - an incomplete strawperson proposal for how to manage complex, shared components.
We have a bunch of different front end dependencies shared between different MFEs, some of which are only used for edx.org and some only for Open edX. Is it worth trying to roll these up together somehow for easier management?
All the different repos are making code sharing harder
Packaging concerns change a lot when we can drop IE11 support and switch to HTTP2
Semantic git commit messages +3
https://github.com/facebook/docusaurus/blob/master/CONTRIBUTING.md#semantic-commit-messages
https://github.com/facebook/docusaurus/blob/master/CHANGELOG-2.x.md
Makes us think a little more about what kind of change we’re making
Refactor broken out into a separate commit
Flags to community what kinds of changes were made (aid in creating / supplement to changelog)
Note that some edXers may always squash all their commits. But other edXers do keep their commits logically separate.
How might we enforce something like this?
commit-lint - pre-commit hook
"husky": { "hooks": { "pre-commit": "npm run lint", "commit-msg": "commitlint -e $GIT_PARAMS" } },
PR titles today also have Jira ticket numbers
Could they be in the description of the PR instead?
Ideas on doing upgrades more efficiently in the future? +3
Would be good to know the priority order and sequencing of upgrades.
Sometimes based on repo ownership priority, sometimes technical reasons like dependency chains
Some teams own too many things, hard for them to get upgrades done in a timely manner
Some teams aren’t yet familiar enough with the stuff they own to feel confident in safely upgrading a thing quickly
We should articulate better why we’re upgrading a thing now and consequences of deferring
Repo health dashboard checks for progress and consistency tracking
“Ticket all the places we need to upgrade this” tickets
Inconsistency of services being in devstack and/or sandboxes makes it a little hard to follow a pattern for upgrading all the things
GitHub Actions migration +2
We aren’t taking advantage of actions declared at the org level yet
Repo health checks for consistent usage of actions would be handy
Cookiecutter updating to use GH Actions instead of Travis has been ticketed
Backlog of Questions/Discussions
This section lists a backlog of previous proposed topics that haven’t yet been discussed.
Recent MFE docs
Requirements for public reposarchived - how will these requirements be reinforced? +1
https://backstage.io/ - Could be a good UI for our health dashboard.