[Feedhenry-raincatcher] RainCatcher Monorepo
Paolo Haji
phaji at redhat.com
Mon Mar 6 13:24:23 UTC 2017
Hey guys,
Just some extra info that this error comes from a premature update from
fh-wfm-mediator at 0.0.15 to 0.1.x (in this case it seems to be in the
raincatcher-user module).
But as Jameel pointed out these bugs are being tracked down atm.
On Mar 6, 2017 1: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/rainca
>> tcher/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/rainca
>> tcher/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/rainca
>> tcher/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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170306/14ae042e/attachment.htm>
More information about the Feedhenry-raincatcher
mailing list