Re-enable openedx/cla status check for the master branch

[adamstankiewicz]

All repos in the openedx Github organization now require the openedx/cla check to pass for commits to master. This repo, however, relies on Lerna to publish the various packages within this JS monorepo to NPM. Lerna utilitizes semantic-release to commit directly to master, which will not pass the openedx/cla check.

As a temporary work around, we have disabled the required openedx/cla status check for this repository.

We will address the issue of committing directly to master by finding another workaround (e.g., opening a new PR that gets automerged with the changes, giving an opportunity for the openedx/cla status check to occur).

[arbrandes]

I'll bring this up internally at tCRIL today, and report back here with findings.

[arbrandes]

This has been discussed on Slack and meetings, and for legal reasons the CLA check was immediately re-enabled.

The purpose of this issue (unless there's another one I'm forgetting), would now be to find another way around the problem.

[arbrandes]

@adamstankiewicz, IIRC a way around this was found: should be document it here and close the issue?

[jmbowman]

I think the workaround was "bypass the release automation and do all the contained package releases manually", which isn't sustainable in the long term. But having just seen openedx/wg-frontend#165 - is that a better solution for "multiple packages in one repo" that we could use here instead of Lerna?

[adamstankiewicz]

@arbrandes There is a manual workaround for now, yes, though it still has some issues (IIRC, it won't automatically create a GitHub release). I unfortunately haven't had the time to check in on what the manual workaround steps actually are yet; we've recently had a couple releases go out, shepherded by my manager @macdiesel. I'll check in with Brian, but I believe the intent still is to get the documentation in place within the repo.

We could probably close this issue given there is a manual workaround, or we could keep it open until the documentation is in place. Either way works here.

---

But having just seen openedx/wg-frontend#165 - is that a better solution for "multiple packages in one repo" that we could use here instead of Lerna?

@jmbowman AFAIK, NPM workspaces alone don't really help with publishing to NPM. For example, here in frontend-enterprise, we're already using NPM workspaces alongside Lerna.

We use NPM workspaces to be able to run NPM scripts across all packages in the repo, but rely on Lerna (and its use of semantic-release) for the publishing to NPM. I found this article to be a good overview on the historical context for semantic-release and monorepo support: https://dev.to/antongolub/the-chronicles-of-semantic-release-and-monorepos-5cfc

Also, Lerna is a widely adopted/accepted solution for JS monorepos. I don't think we should rule it out for other future JS monorepos just because frontend-enterprise alone ran into these issues in figuring out how to properly configure it to get around the required openedx/cla status check.

[arbrandes]

Seems reasonably documented in the comment above, to me! I'm fine with closing it.