Skip to content
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

Closed
adamstankiewicz opened this issue Dec 6, 2022 · 6 comments
Closed

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

adamstankiewicz opened this issue Dec 6, 2022 · 6 comments
Assignees

Comments

@adamstankiewicz
Copy link
Member

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
Copy link

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

@arbrandes
Copy link

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 arbrandes removed their assignment Mar 1, 2023
@arbrandes
Copy link

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

@arbrandes arbrandes moved this from Backlog to In progress in Frontend Working Group May 23, 2023
@jmbowman
Copy link

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
Copy link
Member Author

@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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Closed
Development

No branches or pull requests

3 participants