This requires renaming the account in Google Apps at the time we
deploy this; we'll probably want to do this during off hours to avoid
any user-visible downtime.
This also updates some related email addresses.
(imported from commit fce7629b359a4f278bbf7815c8d177a8fa0484fe)
Before these examples weren't obviously blocking calls (they seemed
more like a callback registration, which may make more sense in the future)
(imported from commit 78fdf98d791b19843526437c710901d8dff62e8c)
This mirrors all the "events" in a Basecamp account onto a stream in Zulip
(default "basecamp"); it sets the topic as the calendar or project that the
event belongs to.
Unfortunately, Basecamp will not host hooks, and neither do we, so this script
is currently intended to be run by our customers, much like the Trello mirror.
(imported from commit 484bc12681a43cd01fe0189c072ab4230eb32c22)
Previously it only provided the list of all public streams; now it
allows one to specify any union of some of the following:
* all public streams
* all streams the user subscribed to
(the most relevant being the union of those two, which is what we want
for the "streams" page).
Or:
* all streams in realm (superuser only)
The manual task required is that when this is pushed to prod, we need
to also deploy the new sync-public-streams version to zmirror.
(imported from commit 27848b8bd136e2777f399b7d05b2fdcec35e4e21)
When we deploy this, we'll need to of course actually build and deploy
the new API tarball.
(imported from commit 03c853e8a9424a63f1c74bb83637d5a1e50a159a)
This makes our life a bit nicer if the message is super-long,
because then even when it's "condensed", we still get a link
to the actual article.
(imported from commit 32e70d29cb702ce73f6cd0c04dbc58457cd2e6b5)
Even though we support a command-line option of --user=,
it gets stored in a field called 'email'.
(imported from commit f2956524517a93187ed182caf8e2d85ccbc1a0f4)
Previously, we would return a JSONDecodeError to the user in the event
that the server returned a 500 error (or other non-JSON content).
(imported from commit 1624dfec6ac65d34216f4de91e33116a54e414fa)
urlparse.urljoin(base_url, url) will drop any path inside base_url if
either the url has a leading "/" or base_url doesn't have a trailing
"/". So adjust our API bindings to ensure that doesn't happen.
(imported from commit c080ee8c04b89127888609da28afc8b388af1911)
This must be deployed after we update our running nginx configuration
to serve api.humbughq.com.
(imported from commit b5c34ebdd595f55eecd6dca6a18a37f105107bd5)
Since in the future we might want requests to add subscriptions to
include things like colors, in_home_view, etc., we're changing the
data format for the add_subscriptions API call to pass each stream as
a dictionary, giving a convenient place to put any added options.
The manual step required here is updating the API version in AFS
available for use with the zephyr_mirror.py system.
(imported from commit 364960cca582a0658f0d334668822045c001b92c)
I believe this should require no special work on deploy, since some
grepping of logs suggests we are not currently using this API query.
(imported from commit 240086f900c6680cbc90bf6a2f334a9e1f172df6)
The --site= option is really only for internal developer use, so I
don't think we gain anything from being strict about it.
(And it doesn't help that the error message one gets pre-this-patch is
super confusing). Fixes Trac #937.
(imported from commit 8d699982aa6830f9eae2bccd6d0c7a1e0e53dd56)
Give better examples, and rewrite options parsing to be more consistent across examples.
Make it more obvious that you can use "--user" and "--api-key" with our python examples.
This bumps our python bindings to v0.1.9
(imported from commit 297468088f864b7d585e567dc45523ea681f1856)
Previously our receive API bindings were broken in our API tarballs
because we weren't including the receive API bindings which they used.
This requires our deploying the built API tarball to the prod server
when we deploy it so that the link on /api isn't broken.
(imported from commit 14ecaab34556f4e29c72f4f567d8af73c89d6297)
Currently the interface for editing messages is limited to a
command-line API tool; it's great for testing with e.g.:
./api/examples/edit-message --message=348135 --content="test $(date +%s)" --site=http://localhost:9991 --subject="test"
The next commit will add a user interface for actually doing the editing.
(imported from commit bdd408cec2946f31c2292e44f724f96ed5938791)
This post-commit hook depends on pysvn. After a transaction is completed,
a Humbug is sent to a configurable stream with the repo modified, actor,
and commit message.
(imported from commit 75cab82d5fe993ea7c4c05be07a7b61e770aff81)
Now that we're distributing these examples, we shouldn't be promoting
the use of the "--site" option.
(imported from commit 01ded4a851dc799fa6c7e902e937c4331ed92bf8)
The previous version of our code only worked with python-requests <
1.0 (as is the case on our servers), the new version will work with
any python-requests new enough to have a .json at all.
(imported from commit 77ffe3e0d890fe88776c313e0e3289aee1bb30ea)
Previously we sent it always as "data", which caused problems for GET
requests where there is no request body.
(imported from commit 20084d1da1b8228cc484536ca4d6f77f547a9d78)
We also switch the Python client to use a client string of "API: Python"
to allow us to determine more easily which bindings our users are using.
(imported from commit 7216c3d150b371835f14d1bc8d81979a92e44925)
After this commit, we built an API tarball and sent it to
CUSTOMER4, and then promptly reverted the commit so that
we could continue as we had been before.
(imported from commit 662519a79edd508e7c115b451a7ec6fbdf1fc0a4)
To incorporate the site parsing fix from a couple weeks ago.
Before deploying this to prod we need to run build-api-tarball and
deploy the code to humbughq.com as for usual API releases.
(imported from commit f6711f5cc07d174c30866029032a595ecee785a3)
At Ksplice we used /usr/bin/python because we shipped dependencies as Debian /
Red Hat packages, which would be installed against the system Python. We were
also very careful to use only Python 2.3 features so that even old system
Python would still work.
None of that is true at Humbug. We expect users to install dependencies
themselves, so it's more likely that the Python in $PATH is correct. On OS X
in particular, it's common to have five broken Python installs and there's no
expectation that /usr/bin/python is the right one.
The files which aren't marked executable are not interesting to run as scripts,
so we just remove the line there. (In general it's common to have libraries
that can also be executed, to run test cases or whatever, but that's not the
case here.)
(imported from commit 437d4aee2c6e66601ad3334eefd50749cce2eca6)
We need to run build-api-tarball and release it on prod when pushing
this commit to prod.
(imported from commit 09e86500d2d208b1972c87444b4c2d56faafc8e6)
Before pushing this to prod, we need to build the 0.1.2 API tarball
and deploy it to the appropriate place on our servers.
(imported from commit ec1a07b3cc2a3e360dac32823ff7cd9de9de1da2)
Previously we were installing data files to e.g. /usr/local/example
and /usr/local/integrations, which is really not OK.
(imported from commit 0efb50412f93efabfe55443d5cac57a8ebb9fe06)
This works much better for working with staging, since rather than
needing to tell each individual tool that you're using staging, you
just specify that along with your API (which at the moment implies
whether you should be using staging or prod).
(imported from commit c1de8e72c24f35ef2160bce5339a5f03c6e1da95)
Tim Abbott
Jessica McKellar
Leo Franchi
Zev Benjamin
Steve Howell
acrefoot
Waseem Daher
Tim Abbott
Scott Feeney
Scott Feeney
Luke Faraone
Zev Benjamin
Leo Franchi
Waseem Daher
Keegan McAllister