Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard

[Deshani Geethika]

Thanks a lot. Will try these and let you know

On Fri, Jul 27, 2018 at 8:52 PM Dave Brondsema  wrote:

> Sure, here's some thoughts:
>
> Inheriting from TestGitRepo means it gets all the test_* functions, so
> when I
> ran nosetests, it ran a lot of TestGitRepo.test_* tests too, which we
> don't want
> to happen.  So I'd remove that inheritance.  You probably will have to
> duplicate
> the setup_with_tools() function in this file then.
>
> Actually, inheriting from _TestCase in
> forgegit/tests/functional/test_controllers.py might be a good option.  It
> has
> some setup functions you can use (so you don't have to duplicate
> setup_with_tools) and it doesn't have any test_* functions.
>
> The super() call is supposed to use its own name, like
> super(TestMergeRequestsSection, self).setUp()  Not sure if that makes a
> difference here or not.
>
> merge_request() is a function but you don't have parenthesis on `mr=
> self.merge_request` so that function isn't running.
>
> I realized what happened earlier when I didn't see the "Tickets" section
> in the
> HTML output of the tickets test!  When I was trying this test now, I got a
> similar situation where the "Merge Requests" section isn't in the HTML
> output at
> all either.  So I looked in the 'test.log' file (where logging goes to
> during
> tests) and saw "Error rendering section MergeRequestsSection: ..." with
> error
> details.  So these sections trap errors and log them, instead of letting
> the
> whole page error.  So looking at the test.log output can help see those
> errors
> when they happen.
>
> You may need to run ThreadLocalODMSession.flush_all() after creating the
> merge
> request object.  That is a common test pattern we have when tests create
> something and then need to view it.  (Mainly needed in tests, since
> regular web
> pages will flush at the end of each request).
>
> Hope that helps, let me know how far you get, and I can look at it some
> more if
> needed :)
>
> On 7/27/18 9:11 AM, Deshani Geethika wrote:
> > Hi Dave,
> >
> > I have started to write a test case for Merge Requests Section. For that
> I
> > have followed ForgeGit tests but it doesn't work for me. I was trying to
> > create a merge request and see whether it appears in dashboard.
> >
> > I've pushed the code into my fork
> > <
> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/96613c7854d116130455a343c814e853c2b5d812/
> >.
> > Can you kindly take a look at that? Also, please let me know any
> debugging
> > process can be done for methods called internally when creating a merge
> > request.
> >
> > Regards!
> >
> > On Tue, Jul 17, 2018 at 11:19 PM Deshani Geethika <
> deshanigeeth...@gmail.com>
> > wrote:
> >
> >> Hi Dave,
> >>
> >> Thank you for sharing these valuable information. I have added a merge
> >> request <
> https://forge-allura.apache.org/p/allura/git/merge-requests/269/>.
> >> Please review it and let me know any further improvements.
> >>
> >> Regards!
> >>
> >> On Mon, Jul 16, 2018 at 9:54 PM Dave Brondsema 
> wrote:
> >>
> >>> On 7/16/18 9:49 AM, Deshani Geethika wrote:
>  Hi Dave,
> 
>  I have tried with adding above lines, but still doesn't work. Can you
> >>> take
>  a look at my implementation
>  <
> >>>
> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/a7ddd0c0bbcfe89cb14fc5214deff168cbb20477/
> 
>  ?
> 
>  Thanks!
> 
> >>>
> >>> Here's some debugging process I did, you can try it too:
> >>>
> >>> Tests use the MockSOLR class instead of a real solr instance (so that
> you
> >>> don't
> >>> need solr to run tests).  I knew that, so I started by going to
> >>> MockSOLR.search() and putting in some print statements to debug it.  At
> >>> the
> >>> beginning of search() I added:
> >>>
> >>> print q
> >>> print fq
> >>>
> >>> And inside the "for obj in self.db.values():" loop, I added "print obj"
> >>>
> >>> My idea was to see what query is happening and what the stored objects
> >>> are, and
> >>> see what's not working.  I ran just the single test with `nosetests
> >>>
> >>>
> allura.tests.functional.test_personal_dashboard:TestTicketsSection.test_tickets_section`
> >>> I noticed there was a 'project_id_s' in the search query, and there
> >>> shouldn't
> >>> be.  But after a bit of trial & error to see what was happening, I
> >>> realized that
> >>> was coming from a "update_bin_count" background task, and that wasn't
> >>> related to
> >>> the test really.
> >>>
> >>> So I commented-out the tasks M.MonQTask.run_ready() to avoid all the
> >>> background
> >>> tasks for now and did it again, and there wasn't any of my print
> >>> statements
> >>> occurring.  So the dashboard ticket search wasn't even happening it
> seems.
> >>>
> >>> Then I printed the "response.html" variable to look at the whole
> >>> dashboard page
> >>> and I didn't see the Tickets section in it at all.  So indeed, that
> >>> section
> >>> isn't included in this test at all for some 

Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard

[Dave Brondsema]

Sure, here's some thoughts:

Inheriting from TestGitRepo means it gets all the test_* functions, so when I
ran nosetests, it ran a lot of TestGitRepo.test_* tests too, which we don't want
to happen.  So I'd remove that inheritance.  You probably will have to duplicate
the setup_with_tools() function in this file then.

Actually, inheriting from _TestCase in
forgegit/tests/functional/test_controllers.py might be a good option.  It has
some setup functions you can use (so you don't have to duplicate
setup_with_tools) and it doesn't have any test_* functions.

The super() call is supposed to use its own name, like
super(TestMergeRequestsSection, self).setUp()  Not sure if that makes a
difference here or not.

merge_request() is a function but you don't have parenthesis on `mr=
self.merge_request` so that function isn't running.

I realized what happened earlier when I didn't see the "Tickets" section in the
HTML output of the tickets test!  When I was trying this test now, I got a
similar situation where the "Merge Requests" section isn't in the HTML output at
all either.  So I looked in the 'test.log' file (where logging goes to during
tests) and saw "Error rendering section MergeRequestsSection: ..." with error
details.  So these sections trap errors and log them, instead of letting the
whole page error.  So looking at the test.log output can help see those errors
when they happen.

You may need to run ThreadLocalODMSession.flush_all() after creating the merge
request object.  That is a common test pattern we have when tests create
something and then need to view it.  (Mainly needed in tests, since regular web
pages will flush at the end of each request).

Hope that helps, let me know how far you get, and I can look at it some more if
needed :)

On 7/27/18 9:11 AM, Deshani Geethika wrote:
> Hi Dave,
> 
> I have started to write a test case for Merge Requests Section. For that I
> have followed ForgeGit tests but it doesn't work for me. I was trying to
> create a merge request and see whether it appears in dashboard.
> 
> I've pushed the code into my fork
> .
> Can you kindly take a look at that? Also, please let me know any debugging
> process can be done for methods called internally when creating a merge
> request.
> 
> Regards!
> 
> On Tue, Jul 17, 2018 at 11:19 PM Deshani Geethika 
> wrote:
> 
>> Hi Dave,
>>
>> Thank you for sharing these valuable information. I have added a merge
>> request .
>> Please review it and let me know any further improvements.
>>
>> Regards!
>>
>> On Mon, Jul 16, 2018 at 9:54 PM Dave Brondsema  wrote:
>>
>>> On 7/16/18 9:49 AM, Deshani Geethika wrote:
 Hi Dave,

 I have tried with adding above lines, but still doesn't work. Can you
>>> take
 a look at my implementation
 <
>>> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/a7ddd0c0bbcfe89cb14fc5214deff168cbb20477/

 ?

 Thanks!

>>>
>>> Here's some debugging process I did, you can try it too:
>>>
>>> Tests use the MockSOLR class instead of a real solr instance (so that you
>>> don't
>>> need solr to run tests).  I knew that, so I started by going to
>>> MockSOLR.search() and putting in some print statements to debug it.  At
>>> the
>>> beginning of search() I added:
>>>
>>> print q
>>> print fq
>>>
>>> And inside the "for obj in self.db.values():" loop, I added "print obj"
>>>
>>> My idea was to see what query is happening and what the stored objects
>>> are, and
>>> see what's not working.  I ran just the single test with `nosetests
>>>
>>> allura.tests.functional.test_personal_dashboard:TestTicketsSection.test_tickets_section`
>>> I noticed there was a 'project_id_s' in the search query, and there
>>> shouldn't
>>> be.  But after a bit of trial & error to see what was happening, I
>>> realized that
>>> was coming from a "update_bin_count" background task, and that wasn't
>>> related to
>>> the test really.
>>>
>>> So I commented-out the tasks M.MonQTask.run_ready() to avoid all the
>>> background
>>> tasks for now and did it again, and there wasn't any of my print
>>> statements
>>> occurring.  So the dashboard ticket search wasn't even happening it seems.
>>>
>>> Then I printed the "response.html" variable to look at the whole
>>> dashboard page
>>> and I didn't see the Tickets section in it at all.  So indeed, that
>>> section
>>> isn't included in this test at all for some reason.
>>>
>>> Hopefully those are some helpful examples for this particular situation
>>> and also
>>> ideas for how to debug high level (like "is it even running?") and low
>>> level (to
>>> see where things might be not working).
>>>
>>> Next step of course is to figure out why in this test the dashboard
>>> section
>>> isn't even running.  I'll let you work on that.  My general strategy is

[allura:tickets] Re: #8204 Create new neighbourhood

[Dave Brondsema]

Those are not part of the open source Allura, sorry


---

** [tickets:#8204] Create new neighbourhood**

**Status:** open
**Milestone:** unreleased
**Created:** Fri Jun 08, 2018 06:15 AM UTC by Vrinda
**Last Updated:** Thu Jul 26, 2018 12:34 PM UTC
**Owner:** nobody


Hello,

I understand neighbourhoods can be used for grouping similar projects. By 
default I can see 3 neighbourhoods created by default : Adobe, Projects and 
Users.
Is it possible to create new neighbourhood?

Regards,
Vrinda.


---

Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed 
to https://forge-allura.apache.org/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://forge-allura.apache.org/p/allura/admin/tickets/options.  Or, if this is 
a mailing list, you can unsubscribe from the mailing list.

Re: [GSoC] [COMDEV-254] Allura - Personal Dashboard

[Deshani Geethika]

Hi Dave,

I have started to write a test case for Merge Requests Section. For that I
have followed ForgeGit tests but it doesn't work for me. I was trying to
create a merge request and see whether it appears in dashboard.

I've pushed the code into my fork
.
Can you kindly take a look at that? Also, please let me know any debugging
process can be done for methods called internally when creating a merge
request.

Regards!

On Tue, Jul 17, 2018 at 11:19 PM Deshani Geethika 
wrote:

> Hi Dave,
>
> Thank you for sharing these valuable information. I have added a merge
> request .
> Please review it and let me know any further improvements.
>
> Regards!
>
> On Mon, Jul 16, 2018 at 9:54 PM Dave Brondsema  wrote:
>
>> On 7/16/18 9:49 AM, Deshani Geethika wrote:
>> > Hi Dave,
>> >
>> > I have tried with adding above lines, but still doesn't work. Can you
>> take
>> > a look at my implementation
>> > <
>> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/a7ddd0c0bbcfe89cb14fc5214deff168cbb20477/
>> >
>> > ?
>> >
>> > Thanks!
>> >
>>
>> Here's some debugging process I did, you can try it too:
>>
>> Tests use the MockSOLR class instead of a real solr instance (so that you
>> don't
>> need solr to run tests).  I knew that, so I started by going to
>> MockSOLR.search() and putting in some print statements to debug it.  At
>> the
>> beginning of search() I added:
>>
>> print q
>> print fq
>>
>> And inside the "for obj in self.db.values():" loop, I added "print obj"
>>
>> My idea was to see what query is happening and what the stored objects
>> are, and
>> see what's not working.  I ran just the single test with `nosetests
>>
>> allura.tests.functional.test_personal_dashboard:TestTicketsSection.test_tickets_section`
>> I noticed there was a 'project_id_s' in the search query, and there
>> shouldn't
>> be.  But after a bit of trial & error to see what was happening, I
>> realized that
>> was coming from a "update_bin_count" background task, and that wasn't
>> related to
>> the test really.
>>
>> So I commented-out the tasks M.MonQTask.run_ready() to avoid all the
>> background
>> tasks for now and did it again, and there wasn't any of my print
>> statements
>> occurring.  So the dashboard ticket search wasn't even happening it seems.
>>
>> Then I printed the "response.html" variable to look at the whole
>> dashboard page
>> and I didn't see the Tickets section in it at all.  So indeed, that
>> section
>> isn't included in this test at all for some reason.
>>
>> Hopefully those are some helpful examples for this particular situation
>> and also
>> ideas for how to debug high level (like "is it even running?") and low
>> level (to
>> see where things might be not working).
>>
>> Next step of course is to figure out why in this test the dashboard
>> section
>> isn't even running.  I'll let you work on that.  My general strategy is
>> to put
>> debugging in various places to confirm if things are running with the
>> right
>> values, or where they aren't, and narrow down to the spot where it goes
>> wrong.
>>
>>
>> --
>> Dave Brondsema : d...@brondsema.net
>> http://www.brondsema.net : personal
>> http://www.splike.com : programming
>>   <><
>>
>
>
> --
> *Deshani Geethika*
> Undergraduate at Department of Computer Science and Engineering
> Faculty of Engineering - University of Moratuwa Sri Lanka
> LinkedIn  | GitHub
>  | Mobile - +94776383034
>
>

-- 
*Deshani Geethika*
Undergraduate at Department of Computer Science and Engineering
Faculty of Engineering - University of Moratuwa Sri Lanka
LinkedIn  | GitHub
 | Mobile - +94776383034

[allura:tickets] #8220 Personal Dashboard - Create Tests for Merge Requests Section

[Deshani]

---

** [tickets:#8220] Personal Dashboard - Create Tests for Merge Requests 
Section**

**Status:** in-progress
**Milestone:** unreleased
**Labels:** Personal Dashboard 
**Created:** Fri Jul 27, 2018 12:31 PM UTC by Deshani
**Last Updated:** Fri Jul 27, 2018 12:31 PM UTC
**Owner:** Deshani





---

Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed 
to https://forge-allura.apache.org/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://forge-allura.apache.org/p/allura/admin/tickets/options.  Or, if this is 
a mailing list, you can unsubscribe from the mailing list.