[Feedhenry-raincatcher] RainCatcher Monorepo
Jameel Briones
jbriones at redhat.com
Mon Mar 6 11:40:15 UTC 2017
Hi Peter,
Myself and Michal are working on getting the development branches rebased
and merged into master. There were a few bugs that we found within the
development branches but we've managed to fix those issues now. You can see
the progress in this JIRA: https://issues.jboss.org/browse/RAINCATCH-595. I
think it would be best to wait until the changes in development have been
merged to master before starting on the monorepo?
Kind Regards,
Jameel
On Mon, Mar 6, 2017 at 4:02 AM, Peter Darrow <pdarrow at redhat.com> wrote:
> Hey guys,
>
> So unfortunately I was unable to complete the migration Friday as I had
> hoped. I was testing the demo apps after combining all the master branches,
> but ran into this error:
>
> Error: fh-wfm-mediator/lib/array-store is now located at the
>> fh-wfm-simple-store module, please install it instead.
>> at Object.<anonymous> (/home/summers/Projects/
>> raincatcher/modules/raincatcher-mediator/lib/array-store.js:2:9)
>> at Module._compile (module.js:409:26)
>> at Object.Module._extensions..js (module.js:416:10)
>> at Module.load (module.js:343:32)
>> at Function.Module._load (module.js:300:12)
>> at Module.require (module.js:353:17)
>> at require (internal/module.js:12:17)
>> at Object.<anonymous> (/home/summers/Projects/
>> raincatcher/modules/raincatcher-user/lib/user/store.js:4:18)
>> at Module._compile (module.js:409:26)
>> at Object.Module._extensions..js (module.js:416:10)
>> at Module.load (module.js:343:32)
>> at Function.Module._load (module.js:300:12)
>> at Module.require (module.js:353:17)
>> at require (internal/module.js:12:17)
>> at Object.<anonymous> (/home/summers/Projects/
>> raincatcher/raincatcher-demo-auth/lib/user.js:3:23)
>> at Module._compile (module.js:409:26)
>> at Object.Module._extensions..js (module.js:416:10)
>> at Module.load (module.js:343:32)
>> at Function.Module._load (module.js:300:12)
>> at Module.require (module.js:353:17)
>> at require (internal/module.js:12:17)
>> at /home/summers/Projects/raincatcher/raincatcher-demo-
>> auth/application.js:72:7
>
>
> I thought it may be an issue with my migration script, but turns out this
> occurs with a normal Raincatcher dev environment set up with
> raincatcher-cli (thanks for the help Summers). The error is
> self-explanatory, but means that master is currently broken. Is anyone
> aware that it isn't working? I wanted to hold off and get this remedied (or
> at least confirmed that it's expected) before starting the new monorepo.
>
> I'm going to test the combined "development" in the morning; does anyone
> know if there will be surprises there? In other words, if I checked out
> "development" on all the individual repos, should the demo apps work
> properly?
>
> Peter
>
> On Fri, Mar 3, 2017 at 10:24 AM, Niall Donnelly <ndonnell at redhat.com>
> wrote:
>
>> +1 for the documentation on migrating branches.
>>
>> Other than that Onwards from me!!
>>
>> Nice one Peter!!
>>
>> On Fri, Mar 3, 2017 at 2:15 PM, Peter Darrow <pdarrow at redhat.com> wrote:
>>
>>> Summers I think we'll leave the final code at HEAD. I agree while the
>>> project is small and we're iterating quickly that we should keep things
>>> centralized. As far as manual QA of the portal app goes, I think that's a
>>> good idea for a sanity check. And re: blog post, I have no problem writing
>>> that!
>>>
>>> Emilio: Great point, I will document the steps required to migrate
>>> active branches—it will probably be manual but pretty straightforward I
>>> think.
>>>
>>> *Note: I plan on completing this migration today. If you have strong
>>> feelings for or against this, please voice them in the next few hours.*
>>>
>>> On Fri, Mar 3, 2017 at 7:07 AM, Emilio Rodriguez Martinez <
>>> emrodrig at redhat.com> wrote:
>>>
>>>> Any idea on how are we going to migrate our unfinished work to the
>>>> monorepo? I think it would be nice to prepare a quick email explaining the
>>>> steps needed to do this as I guess it will be quite a manual process.
>>>>
>>>> Other than that everything looks good to me, I'm really looking forward
>>>> to see this working :)
>>>>
>>>> On Thu, Mar 2, 2017 at 7:10 PM, Summers Pittman <supittma at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 1, 2017 at 8:58 AM, Peter Darrow <pdarrow at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> So after chatting with Paolo and Wojciech last week, we decided it
>>>>>> probably makes the most sense to just migrate the migrate the master and
>>>>>> development branches from each repo, and leave the repos up (with
>>>>>> deprecation warnings on them) for any other branches people are working on
>>>>>> or tags we need.
>>>>>>
>>>>>
>>>>> +1, will we leave the final code at HEAD or will we clear it our and
>>>>> leave the code at HEAD~1?
>>>>>
>>>>>
>>>>>>
>>>>>> I've pushed up this proposed structure to https://github.com/feedhenr
>>>>>> y-raincatcher/raincatcher. As you can see, development is 220
>>>>>> commits ahead of master. Does this seem right to you guys? You can see the
>>>>>> comparison here: https://github.com/feedhenry-r
>>>>>> aincatcher/raincatcher/compare/development. Approximately 35 of the
>>>>>> commits are merges I made as a part of the migration, but that still leave
>>>>>> 185 commits ahead which seems like a lot.
>>>>>>
>>>>>>
>>>>> /s/apps/demos or examples?
>>>>>
>>>>> Eventually we may want to break the examples into their own project
>>>>> (ex https://github.com/wildfly-swarm/wildfly-swarm-examples), but
>>>>> right now while the project is small and we are doing a lot of quick
>>>>> development keeping them together makes a lot of sense.
>>>>>
>>>>>
>>>>>> The next steps I propose are:
>>>>>>
>>>>>> 1. Configure travis to build all of the projects in the monorepo
>>>>>> (on each branch and PR)
>>>>>> 2. Identify and manually migrate any branches that people are
>>>>>> working on outside of master and development
>>>>>> 3. Choose a day/time to stop development on the individual repos
>>>>>> (likely late on a Friday)
>>>>>> 4. Run the migration script one last time
>>>>>> 5. Resume regular development on the monorepo
>>>>>> 6. Update script(s) for publishing releases to npm
>>>>>>
>>>>>> Does this seem reasonable to everyone? I was thinking this Friday
>>>>>> might be a good opportunity to switch over, but I'd love to get your
>>>>>> feedback.
>>>>>>
>>>>>
>>>>> It seems reasonable, maybe add a run of the portal app in here as
>>>>> well? Also who is going to write the blog post to discuss the migration?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Cheers,
>>>>>> Peter
>>>>>>
>>>>>> On Thu, Feb 23, 2017 at 11:41 AM, Paolo Haji <phaji at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Along with lerna we can start adding global utils to the top level,
>>>>>>> so `*npm start*` could fire up all demo-apps (with optional task
>>>>>>> runner and through forever/nodemon). If we move to a nice logging library
>>>>>>> like debug <https://github.com/visionmedia/debug> we can have
>>>>>>> consolidated logs and in a filterable form that would be useful for both
>>>>>>> local dev and cluster deployments.
>>>>>>>
>>>>>>> As for tags, I'm not sure it will be of much value keeping their
>>>>>>> history since they'll not be actual tags that show up as GH releases, we
>>>>>>> can keep the old repos around as reference until then.
>>>>>>>
>>>>>>> Our releases as a monorepo would be consolidating all version
>>>>>>> numbers across all modules right? We can start off with a new major c.f. angular
>>>>>>> 4.x
>>>>>>> <http://angularjs.blogspot.com.br/2016/12/ok-let-me-explain-its-going-to-be.html>
>>>>>>>
>>>>>>> On Thu, Feb 23, 2017 at 12:19 PM, Peter Darrow <pdarrow at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Wojciech as I mentioned the tool is buggy and really doesn't make a
>>>>>>>> master branch, I think it leaves that up to us. I was mostly looking for
>>>>>>>> feedback on the approach. So is this what you're proposing:
>>>>>>>>
>>>>>>>> 1. Move the demo apps into a "apps" subdirectory
>>>>>>>> 2. Move the modules into a "packages" subdirectory
>>>>>>>> 3. Move the documentation into a "docs" subdirectory
>>>>>>>> 4. Combine all branches named "master" from each individual
>>>>>>>> repo into one master branch
>>>>>>>> 5. Combine all branches named "development" from each
>>>>>>>> individual repo into one master branch
>>>>>>>> 6. Copy the tags from each individual repo to the monorepo with
>>>>>>>> the following naming scheme: "<original tag name>-<original repo name>"
>>>>>>>> 7. Ensured the history stays intact.
>>>>>>>>
>>>>>>>> #6 is the one I'm most curious about—how should we attempt to
>>>>>>>> migrate these tags? Or do we not migrate at all as Emilio suggests and just
>>>>>>>> keep the old repos around for resurrecting old tags, etc.?
>>>>>>>>
>>>>>>>> Emilio as far as building and running the apps, https://lernajs.io/
>>>>>>>> should help us with some of this but we may need a small script to help
>>>>>>>> devs run all the apps at once (a slimmed down raincatcher-cli maybe?). Any
>>>>>>>> suggestions there?
>>>>>>>>
>>>>>>>> Peter
>>>>>>>>
>>>>>>>> On Thu, Feb 23, 2017 at 10:49 AM, Wojciech Trocki <
>>>>>>>> wtrocki at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Where is master :P ?
>>>>>>>>>
>>>>>>>>> Import seems to be doing something we do not want - creating new
>>>>>>>>> branch for each of the module. Best would be to have only 2 branches for
>>>>>>>>> that mono repo:
>>>>>>>>> - master (containing all modules from master with history)
>>>>>>>>> - development (with all modules from development branch)
>>>>>>>>>
>>>>>>>>> Having it this way would mean that we would not be able to have
>>>>>>>>> every component on development branch.
>>>>>>>>> If perl is a problem maybe we should use some different tools.
>>>>>>>>> Fastline migration seems to be something we can use:
>>>>>>>>>
>>>>>>>>> https://github.com/fastlane/monorepo/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Wojciech Trocki
>>>>>>>>> Red Hat Mobile
>>>>>>>>>
>>>>>>>>> On Thu, Feb 23, 2017 at 2:21 PM, Peter Darrow <pdarrow at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hey all,
>>>>>>>>>>
>>>>>>>>>> I spent a bunch of time yesterday stitching together our repos
>>>>>>>>>> into a single repo. My goal was to try and identify issues that might make
>>>>>>>>>> this challenging. You can see the results here:
>>>>>>>>>> https://github.com/feedhenry-raincatcher/raincatcher-stitched/.
>>>>>>>>>> My approach was the following:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 1. Move the demo apps into a "apps" subdirectory
>>>>>>>>>> 2. Move the modules into a "packages" subdirectory
>>>>>>>>>> 3. Move the documentation into a "docs" subdirectory
>>>>>>>>>> 4. Copy the branches from each individual repo to a branch on
>>>>>>>>>> the monorepo with the following naming scheme: "<original branch
>>>>>>>>>> name>-<original repo name>".
>>>>>>>>>> 5. Copy the tags from each individual repo to the monorepo
>>>>>>>>>> with the following naming scheme: "<original tag name>-<original repo name>"
>>>>>>>>>> 6. Ensured the history stays intact.
>>>>>>>>>>
>>>>>>>>>> I found a tool that promised to implement this exact approach (
>>>>>>>>>> http://search.cpan.org/dist/Git-FastExport/script/git-stitch-repo).
>>>>>>>>>> It's written in Perl and I spent an unreasonable amount of time yesterday
>>>>>>>>>> trying to configure my system to install CPAN modules :/. Eventually I got
>>>>>>>>>> it working, but if you take a look at the stitched repo, it seems to have
>>>>>>>>>> done an incomplete job. I'm not a Perl developer so I don't think it would
>>>>>>>>>> be worth my time to try to contribute a fix, but I think I could implement
>>>>>>>>>> something similar with a bit of effort.
>>>>>>>>>>
>>>>>>>>>> What do you guys think—do we need to migrate all of the branches
>>>>>>>>>> from each repo, or just the master from each one? Do we care about the
>>>>>>>>>> history? Is it important to keep every single tag? Let me know what you
>>>>>>>>>> think!
>>>>>>>>>>
>>>>>>>>>> Peter
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Feedhenry-raincatcher mailing list
>>>>>>>>>> Feedhenry-raincatcher at redhat.com
>>>>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Feedhenry-raincatcher mailing list
>>>>>>>> Feedhenry-raincatcher at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Feedhenry-raincatcher mailing list
>>>>>> Feedhenry-raincatcher at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Feedhenry-raincatcher mailing list
>>>>> Feedhenry-raincatcher at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Feedhenry-raincatcher mailing list
>>> Feedhenry-raincatcher at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>
>>>
>>
>
> _______________________________________________
> Feedhenry-raincatcher mailing list
> Feedhenry-raincatcher at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170306/522b2f7d/attachment.htm>
More information about the Feedhenry-raincatcher
mailing list