liferay
Consider steps to automate release and portal updating process
At some point I think it would be helpful if we had some sort of automated process for releasing clay and send a PR to update portal.
Things to consider:
- Knowing when we need to update implementations of clay, we can't really automate this.
- Versioning, is it easier to automate if we go back to "locked" mode in lerna?
- Should this be a local command we run or a gh action?
Anyways, I have been randomly thinking about this and thought I would create an issue to remind us to investigate.
It would be great! I've been thinking the same thing. I was thinking that we could try to do something using Github Actions but I think they could only be triggered via branch.
Having something like this would make releasing and integrating probably easier... we could even somehow do nightly PRs just to check that whatever's been merged (even if not released) is working fine or detect issues early before we release and attempt to integrate.
- Should this be a local command we run or a gh action?
My suspicion is that anything related to liferay-portal isn't really suitable for a GitHub action, because you need a copy of liferay-portal in order to do things like create a PR for it, and the repo is too large for that to be feasible (I ran into this trying to set up a GitHub action to auto-update the liferay-frontend/liferay-portal repo; it runs in a VM which is too slow to fetch the repo, and caching doesn't save you...).
Working on the local command isn't a waste of time though. Whatever we can do to make releases "turn-key" will benefit us and in the future if something based on a GitHub action does become feasible, then it's likely our work with the manual process carries over to benefit the automated one too.
Maybe we can do something from the liferay-portal side. Instead of cutting nightly snapshot releases of Clay packages, we could use yarn add <git remote url>#<branch/commit/tag> as described here to point at a specific commit. Might require us to actually commit build artifacts though, or maybe we can use a postinstall script to run the build at install time. Or wrap it all up in a script that we can run from a liferay-portal checkout; it would be a single command (and waiting a few minutes) to get you to the point where you could test HEAD of master in DXP.
we could even somehow do nightly PRs just to check that whatever's been merged (even if not released) is working fine or detect issues early before we release and attempt to integrate.
I really like this idea, whether it's an actual PR or something like @wincent described. This would at least give us a consistent idea of the state of clay in DXP and how difficult an update might be,
Let's start with this idea of a nightly test of latest clay in portal, and then we can iterate from there.
My suspicion is that anything related to liferay-portal isn't really suitable for a GitHub action, because you need a copy of liferay-portal in order to do things like create a PR for it, and the repo is too large for that to be feasible (I ran into this trying to set up a GitHub action to auto-update the liferay-frontend/liferay-portal repo; it runs in a VM which is too slow to fetch the repo, and caching doesn't save you...).
Oh yeah, true! The portal is very large, Action really won't be able to handle it very well and it will probably take a long time.
Let's start with this idea of a nightly test of latest clay in portal, and then we can iterate from there.
Yeah I like that too.
I'm closing this issue, I think the automation part to generate the release automatically for DXP is not something more necessary now, we have a good and faster flow now since the release on Clay's side is all automated being done by Github Action, but I'd also like to maybe in the future have something for automated DXP but for now I think we're fine with that.