[Feedhenry-raincatcher] Lerna-js based monorepo, lets try to migrate now before this dies again!

Wojciech Trocki wtrocki at redhat.com
Fri Mar 31 14:54:33 UTC 2017


On Fri, Mar 31, 2017 at 2:19 PM, Paolo Haji <phaji at redhat.com> wrote:

> Repository moved to https://github.com/feedhenr
> y-raincatcher/raincatcher-mono, basic travis build setup with Wojtek's
> help. You can see the browserify-related error I mentioned in the build
> logs.
>
> Another concern that cropped up by Ger is how we'd set up the deployment
> of the separate apps to the studio template.
> I think that is essentially the same problem of being able to deploy them
> individually to a cluster from a working copy, which could be resolved by
> the same approached as generally used for deploying gh-pages, setting up a
> bare branch with only the relevant subtree and pushing it.
>

+1 for mentioning this problem. I have solution.
Instead of hacking our setup to templates limitations we can just extend
global.json file (
https://github.com/feedhenry/fh-template-apps/blob/master/global.json) to
support folders as additional parameter.

In relation to deployment issues, I think we can just wrap fh-fhc to do all
the required setup for us and deploy things. This should be simple enough
and would allow easy deployments and ticket verification.
Thinks like alpha releases can be also wrapped into tools so there would
not be any need to read documentation.


> On Fri, Mar 31, 2017 at 8:21 AM, Wojciech Trocki <wtrocki at redhat.com>
> wrote:
>
>> Thank you for contribution. Really good work - looking forward to use
>> lerna.
>> I think that the biggest challenge with monorepo is to agree on how we
>> should support or possibly move out from our forking model.
>> Another challenge I see is just a building PR's.
>>
> Sorry I didn't quite understand this sentence.
>

My concerns are gone since I see that build for the app should be quite
fast now.


>
>>
> Having code in one place is good start, but we would also need to fully
>> understand impact of that change to our customers that already forked
>> repositories etc.
>>
> Do you know if they still pick up updates after forking through
> rebasing/cherry picking? I believe some of our lower-level modules are
> probably used as-is but others like raincatcher-user are really intended to
> be forked.
> I just questioning the current ability of them picking up our changes
> currently since they're most likely riddled with conflicts on top of their
> modifications as well.
>

I would collect required information and check if we are restricted on that
level.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170331/4d60d745/attachment.htm>


More information about the Feedhenry-raincatcher mailing list