Setup Instructions
168 views
Skip to first unread message
Aidan
Feb 20, 2012, 4:09:21 AM2/20/12
to bite-discuss
Hi Guys
Seen your presentation and I am curious as how to setup this on our
Dev environment?
E.g. local build and internal servers?
Thanks
Aidan
Seen your presentation and I am curious as how to setup this on our
Dev environment?
E.g. local build and internal servers?
Thanks
Aidan
Jason Stredwick
Feb 21, 2012, 1:17:56 AM2/21/12
to bite-discuss
Basically, you need to have Python 2.7, Java, svn, git, and mercurial
installed on your machine before you can build BITE. Then there is a
python build script you need to run (build.py). The build file will
download all the dependencies and then construct the extension and
server bundles in the output folder. You can find the build command
line options with build.py --help.
As for internal use. The extension can be packaged as a crx and
distributed, hosted to Chrome Webstore for "select testers" or
whatnot, or passed around and loaded as an unpacked extension. The
server is built using Google AppEngine. Use of the dev_appengine for
local machines is not guaranteed to work or persist. If you need to
use an alternative to AppEngine then you will need to provide a port
of the server. The documentation is in a state of flux, but I think
most of it is there. The bug related code is under tools/bugs and rpf
is under tools/rpf. There is also common server code under extension/
server. If there is some piece of the server API that is missing or
is difficult to understand please feel free to post those questions.
When my time frees up again in the near future I plan to finish
documenting the API. This has been a common frustration for many.
Please let me know if there is any other information I can provide you
with.
Jason
installed on your machine before you can build BITE. Then there is a
python build script you need to run (build.py). The build file will
download all the dependencies and then construct the extension and
server bundles in the output folder. You can find the build command
line options with build.py --help.
As for internal use. The extension can be packaged as a crx and
distributed, hosted to Chrome Webstore for "select testers" or
whatnot, or passed around and loaded as an unpacked extension. The
server is built using Google AppEngine. Use of the dev_appengine for
local machines is not guaranteed to work or persist. If you need to
use an alternative to AppEngine then you will need to provide a port
of the server. The documentation is in a state of flux, but I think
most of it is there. The bug related code is under tools/bugs and rpf
is under tools/rpf. There is also common server code under extension/
server. If there is some piece of the server API that is missing or
is difficult to understand please feel free to post those questions.
When my time frees up again in the near future I plan to finish
documenting the API. This has been a common frustration for many.
Please let me know if there is any other information I can provide you
with.
Jason
Josh
Feb 22, 2012, 10:47:11 AM2/22/12
to bite-discuss
So I have been extremely interested in this project since I read about
it a while back.
The biggest hurdle I have to overcome right now is getting it to work
in our environment. The end goal is to basically have BITE hooked up
to FogBugz... which is what we use here at work. This is where I am a
little fuzzy on the architecture of BITE.
Do I need to completely replace the server implemenation with one that
talks to FogBugz API? Assuming I had one ready to go, where are the
integration points? How do I get it hooked up to BITE?
Is there a simpler option? What I am imagining here is some
documentation that says: "Bite makes this call with this JSON payload,
and expects this JSON in return." Does something like that exists? If
so what are the integration points?
As I said before this is a really exciting project to me, but I have
to get this thing hooked up to FogBugz before our QA team / managers
would even think about using it.
-- Josh
it a while back.
The biggest hurdle I have to overcome right now is getting it to work
in our environment. The end goal is to basically have BITE hooked up
to FogBugz... which is what we use here at work. This is where I am a
little fuzzy on the architecture of BITE.
Do I need to completely replace the server implemenation with one that
talks to FogBugz API? Assuming I had one ready to go, where are the
integration points? How do I get it hooked up to BITE?
Is there a simpler option? What I am imagining here is some
documentation that says: "Bite makes this call with this JSON payload,
and expects this JSON in return." Does something like that exists? If
so what are the integration points?
As I said before this is a really exciting project to me, but I have
to get this thing hooked up to FogBugz before our QA team / managers
would even think about using it.
-- Josh
Jason Stredwick
Feb 22, 2012, 12:40:13 PM2/22/12
to bite-discuss
There is no easy answer to your question about integration as there
are multiple valid approaches of which I am unable to guess the time
and effort for. You basically suggest the two primary options: create
your own server or integrate with ours.
1. Create your own server - Yes it would be as simple as creating the
API calls that transmit specific JSON objects. What are those API
calls? This is where I mentioned the documentation is not perfect. I
believe the wiki pages while a huge jumbled mess are complete. Start
with
http://code.google.com/p/bite-project/wiki/serverhandlers
I have changed the bug related calls and have not updated the wiki.
The old version is still in place but the new extension and server
code are under tools/bugs (this is what is running now if you build
and deploy). You can find the API here
https://docs.google.com/document/d/1nQenrOdbpIDPRAPAcQFgx-wExDUhzt1aAVYqRGsxF0s/view?hl=en_US&pli=1
Also, I tried to keep track of my progress in this thread
http://groups.google.com/group/bite-discuss/browse_thread/thread/cf51d5ad0a6b3d43
It provides a lot of useful information as well.
2. Integrate - Just because you are using internal tools does not
necessarily prohibit the use AppEngine. While working at Google, the
BITE project served from AppEngine accessing internal bug databases
and TCM, but it also used publicly available bug databases as well at
the same time (issue tracker). This integration point you will find
under the bugs/tools/server/appengine/providers and you can see how it
was done previously at server/crawlers and server/handlers. In the
old version everything was tightly coupled so you will need to dig
around. In the new version, I consider it a work in progress but
should work fine. You will have to define your crawler, pusher, and
indexer for your bug database.
---
I am working towards a vision of BITE that is drop in easy to use with
excellent documentation on the integration points, but I am only part
way there. I only have so much time.
Jason
are multiple valid approaches of which I am unable to guess the time
and effort for. You basically suggest the two primary options: create
your own server or integrate with ours.
1. Create your own server - Yes it would be as simple as creating the
API calls that transmit specific JSON objects. What are those API
calls? This is where I mentioned the documentation is not perfect. I
believe the wiki pages while a huge jumbled mess are complete. Start
with
http://code.google.com/p/bite-project/wiki/serverhandlers
I have changed the bug related calls and have not updated the wiki.
The old version is still in place but the new extension and server
code are under tools/bugs (this is what is running now if you build
and deploy). You can find the API here
https://docs.google.com/document/d/1nQenrOdbpIDPRAPAcQFgx-wExDUhzt1aAVYqRGsxF0s/view?hl=en_US&pli=1
Also, I tried to keep track of my progress in this thread
http://groups.google.com/group/bite-discuss/browse_thread/thread/cf51d5ad0a6b3d43
It provides a lot of useful information as well.
2. Integrate - Just because you are using internal tools does not
necessarily prohibit the use AppEngine. While working at Google, the
BITE project served from AppEngine accessing internal bug databases
and TCM, but it also used publicly available bug databases as well at
the same time (issue tracker). This integration point you will find
under the bugs/tools/server/appengine/providers and you can see how it
was done previously at server/crawlers and server/handlers. In the
old version everything was tightly coupled so you will need to dig
around. In the new version, I consider it a work in progress but
should work fine. You will have to define your crawler, pusher, and
indexer for your bug database.
---
I am working towards a vision of BITE that is drop in easy to use with
excellent documentation on the integration points, but I am only part
way there. I only have so much time.
Jason
Josh
Feb 23, 2012, 12:09:51 PM2/23/12
to bite-discuss
Still struggling to get off the ground with this one.
What I have done is create a simple server that just listens to
traffic and logs the requests coming across. I hope to use this in
order to inspect what is happening and piece by piece add the
functionality I need to make it all work.
However, when I try to modify where BITE points to it doesn't seem to
make a difference.
I modified "extensions\src\options\constants.js" and set the server
constants to something like this:
bite.options.constants.ServerChannelOption = {
DEV: 'http://localhost:9999/BiteServer',
RELEASE: 'http://localhost:9999/BiteServer'
};
From the repository I run "build.py --clean", and then "build.py"
I reload, the extension, but everything seems to still point to the
AppSpot address.
I'm sure I'm doing something horribly wrong, but would be very
grateful to find out what it is :)
-- Josh
On Feb 22, 12:40 pm, Jason Stredwick <jason.stredw...@gmail.com>
wrote:
What I have done is create a simple server that just listens to
traffic and logs the requests coming across. I hope to use this in
order to inspect what is happening and piece by piece add the
functionality I need to make it all work.
However, when I try to modify where BITE points to it doesn't seem to
make a difference.
I modified "extensions\src\options\constants.js" and set the server
constants to something like this:
bite.options.constants.ServerChannelOption = {
DEV: 'http://localhost:9999/BiteServer',
RELEASE: 'http://localhost:9999/BiteServer'
};
From the repository I run "build.py --clean", and then "build.py"
I reload, the extension, but everything seems to still point to the
AppSpot address.
I'm sure I'm doing something horribly wrong, but would be very
grateful to find out what it is :)
-- Josh
On Feb 22, 12:40 pm, Jason Stredwick <jason.stredw...@gmail.com>
wrote:
> There is no easy answer to your question about integration as there
> are multiple valid approaches of which I am unable to guess the time
> and effort for. You basically suggest the two primary options: create
> your own server or integrate with ours.
>
> 1. Create your own server - Yes it would be as simple as creating the
> API calls that transmit specific JSON objects. What are those API
> calls? This is where I mentioned the documentation is not perfect. I
> believe the wiki pages while a huge jumbled mess are complete. Start
> with
>
> http://code.google.com/p/bite-project/wiki/serverhandlers
>
> I have changed the bug related calls and have not updated the wiki.
> The old version is still in place but the new extension and server
> code are under tools/bugs (this is what is running now if you build
> and deploy). You can find the API here
>
> https://docs.google.com/document/d/1nQenrOdbpIDPRAPAcQFgx-wExDUhzt1aA...
> are multiple valid approaches of which I am unable to guess the time
> and effort for. You basically suggest the two primary options: create
> your own server or integrate with ours.
>
> 1. Create your own server - Yes it would be as simple as creating the
> API calls that transmit specific JSON objects. What are those API
> calls? This is where I mentioned the documentation is not perfect. I
> believe the wiki pages while a huge jumbled mess are complete. Start
> with
>
> http://code.google.com/p/bite-project/wiki/serverhandlers
>
> I have changed the bug related calls and have not updated the wiki.
> The old version is still in place but the new extension and server
> code are under tools/bugs (this is what is running now if you build
> and deploy). You can find the API here
>
>
> Also, I tried to keep track of my progress in this thread
>
> http://groups.google.com/group/bite-discuss/browse_thread/thread/cf51...
> Also, I tried to keep track of my progress in this thread
>
Jason Stredwick
Feb 23, 2012, 12:15:25 PM2/23/12
to bite-discuss
Most likely it is the build system; it does not detect changes and
rebuild. For the specific instance of changing the options then you
will need to remove genfiles/options_script.js and genfiles/
background_script.js. For more general changes where you are
uncertain what generated files are touched by your changes then you
will want to do "build.py --clean" before building. This removes the
generated files.
So basically you are modifying then rebuilding but the generated files
aren't changed.
This is a known issue (and annoying) with the build script. It has to
do with using closure and knowing the dependencies for the compiled
scripts. It is a problem we are looking at tackling in the near
future.
I hope this helps
Jason
rebuild. For the specific instance of changing the options then you
will need to remove genfiles/options_script.js and genfiles/
background_script.js. For more general changes where you are
uncertain what generated files are touched by your changes then you
will want to do "build.py --clean" before building. This removes the
generated files.
So basically you are modifying then rebuilding but the generated files
aren't changed.
This is a known issue (and annoying) with the build script. It has to
do with using closure and knowing the dependencies for the compiled
scripts. It is a problem we are looking at tackling in the near
future.
I hope this helps
Jason
Josh
Feb 23, 2012, 3:49:10 PM2/23/12
to bite-discuss
Jason,
Thanks for all your help on this so far.
This is turning out to be hugely beneficial in inspecting the traffic
in order to build out a custom server. I know you said you are busy
and I can work around this for now, but I just wanted to share some of
my findings.
As I mentioned previously I set my server to a location like this:
"http://localhost:9999/BiteServer"
What is interesting is when capturing the requests coming through,
sometimes it honors the full path, and other times only the domain/
port. What I end up with is something like this:
GET /get_logon_status
POST /BiteServer/bugs/urls
GET /get_templates
POST /BiteServer/bugs
GET /BiteServer
As you can see there might be some subtle bugs in how URL's are being
constructed. For now I can work around this by simply omitting the
application name, and just giving it the domain/port.
If there is interest from anyone in what I am doing, and you are
working in a windows/IIS environment, then let me know and I can
publish the bits to github or something.
-- Josh
On Feb 23, 12:15 pm, Jason Stredwick <jason.stredw...@gmail.com>
Thanks for all your help on this so far.
This is turning out to be hugely beneficial in inspecting the traffic
in order to build out a custom server. I know you said you are busy
and I can work around this for now, but I just wanted to share some of
my findings.
As I mentioned previously I set my server to a location like this:
"http://localhost:9999/BiteServer"
What is interesting is when capturing the requests coming through,
sometimes it honors the full path, and other times only the domain/
port. What I end up with is something like this:
GET /get_logon_status
POST /BiteServer/bugs/urls
GET /get_templates
POST /BiteServer/bugs
GET /BiteServer
As you can see there might be some subtle bugs in how URL's are being
constructed. For now I can work around this by simply omitting the
application name, and just giving it the domain/port.
If there is interest from anyone in what I am doing, and you are
working in a windows/IIS environment, then let me know and I can
publish the bits to github or something.
-- Josh
On Feb 23, 12:15 pm, Jason Stredwick <jason.stredw...@gmail.com>
Jason Stredwick
Feb 23, 2012, 3:55:48 PM2/23/12
to bite-discuss
I am glad you got it working! I assume that the base url specified in
the options constants is
"http://localhost:9999/BiteServer"?
That is interesting results. Thanks! I will have to look into it.
There was no uniform url construction amongst the team. I am
wondering if the client expects the base server url to be no more than
domain. Some people use closure url parsing so maybe some are cutting
off the path from the base url before construction? Very intersting.
Feel free to post any interesting results you want to share. I am
sure others would find it useful; not just me.
Jason
the options constants is
"http://localhost:9999/BiteServer"?
That is interesting results. Thanks! I will have to look into it.
There was no uniform url construction amongst the team. I am
wondering if the client expects the base server url to be no more than
domain. Some people use closure url parsing so maybe some are cutting
off the path from the base url before construction? Very intersting.
Feel free to post any interesting results you want to share. I am
sure others would find it useful; not just me.
Jason
Message has been deleted
Aidan
Mar 4, 2012, 2:43:01 PM3/4/12
to bite-discuss
Hey Jason
I got this to build and got it running using
dev_appserver.py c:\bite-project\output\server
and have a login page at the localhost:8080
But after that nothing
on IE I get an error
File "c:\bite-project\output\server\handlers\home.py", line 25, in
<module>
import webapp2
ImportError: No module named webapp2
any ideas
I got this to build and got it running using
dev_appserver.py c:\bite-project\output\server
and have a login page at the localhost:8080
But after that nothing
on IE I get an error
File "c:\bite-project\output\server\handlers\home.py", line 25, in
<module>
import webapp2
ImportError: No module named webapp2
any ideas
Jason Stredwick
Mar 4, 2012, 8:37:17 PM3/4/12
to bite-discuss
Technically, you can use the dev_appengine to run and test. However,
you should know that it has limitations such as lack of persistent
data (I think). I am not that familiar with dev_appengine, perhaps
Alexis will be able to help.
As for the error you are reporting, my first inclination is that you
don't have the most recent AppEngine SDK? webapp2 is supposed to come
as part of the AppEngine SDK as far as I know. I will try to check on
this.
One other thing, just to make sure you are aware, BITE is currently a
Chrome only tool.
Jason
you should know that it has limitations such as lack of persistent
data (I think). I am not that familiar with dev_appengine, perhaps
Alexis will be able to help.
As for the error you are reporting, my first inclination is that you
don't have the most recent AppEngine SDK? webapp2 is supposed to come
as part of the AppEngine SDK as far as I know. I will try to check on
this.
One other thing, just to make sure you are aware, BITE is currently a
Chrome only tool.
Jason
Aidan
Mar 5, 2012, 6:28:30 AM3/5/12
to bite-d...@googlegroups.com
Hi Jason
I got it : )
I have it running on local host
With App Engine 1.6.0 other versions are missing Webapp2 or have other issues
Have any of you guys integrated this with Jira Bug Data bases and how do I add users as I can only login as te...@example.com
Jason thank you for all the help on this
Aidan
I got it : )
I have it running on local host
With App Engine 1.6.0 other versions are missing Webapp2 or have other issues
Have any of you guys integrated this with Jira Bug Data bases and how do I add users as I can only login as te...@example.com
Jason thank you for all the help on this
Aidan
Jason Stredwick
Mar 6, 2012, 9:54:14 AM3/6/12
to bite-discuss
So there are three classes under tools/bugs/server/... called pusher,
indexer, and crawler. Those are the files you will want to extend in
order to make use of a system like Jira. Basically, these files add,
translate, and retrieve bugs from your backend data source.
crawler - keeps Jira and BITE in sync by crawling the bugs in Jira on
a cron (you may have to set up the cron) and adding/updating bug data
stored in BITE as appropriate.
pusher - translates BITE bug data into Jira bug data and pushes the
data to Jira
indexer - takes BITE bug data and breaks it into bug data and url
index map (pretty sure).
Jason
On Mar 5, 3:28 am, Aidan <aidan.mc.do...@gmail.com> wrote:
> Hi Jason
>
> I got it : )
>
> I have it running on local host
>
> With App Engine 1.6.0 other versions are missing Webapp2 or have other
> issues
>
> Have any of you guys integrated this with Jira Bug Data bases and how do I
> add users as I can only login as t...@example.com
indexer, and crawler. Those are the files you will want to extend in
order to make use of a system like Jira. Basically, these files add,
translate, and retrieve bugs from your backend data source.
crawler - keeps Jira and BITE in sync by crawling the bugs in Jira on
a cron (you may have to set up the cron) and adding/updating bug data
stored in BITE as appropriate.
pusher - translates BITE bug data into Jira bug data and pushes the
data to Jira
indexer - takes BITE bug data and breaks it into bug data and url
index map (pretty sure).
Jason
On Mar 5, 3:28 am, Aidan <aidan.mc.do...@gmail.com> wrote:
> Hi Jason
>
> I got it : )
>
> I have it running on local host
>
> With App Engine 1.6.0 other versions are missing Webapp2 or have other
> issues
>
> Have any of you guys integrated this with Jira Bug Data bases and how do I
Reply all
Reply to author
Forward
0 new messages