-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-enable openedx/cla
status check for the master
branch
#282
Comments
I'll bring this up internally at tCRIL today, and report back here with findings. |
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. |
@adamstankiewicz, IIRC a way around this was found: should be document it here and close the issue? |
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? |
@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.
@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 |
Seems reasonably documented in the comment above, to me! I'm fine with closing it. |
All repos in the
openedx
Github organization now require theopenedx/cla
check to pass for commits tomaster
. This repo, however, relies on Lerna to publish the various packages within this JS monorepo to NPM. Lerna utilitizessemantic-release
to commit directly tomaster
, which will not pass theopenedx/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 theopenedx/cla
status check to occur).The text was updated successfully, but these errors were encountered: