- Set up PR fetch aliases to make pulling PRs easy: https://gist.github.com/gnarf/5406589
- Set up RubyMine as external diff viewer in SourceTree: http://www.jetbrains.com/ruby/webhelp/running-rubymine-as-a-diff-or-merge-command-line-tool.html and http://stackoverflow.com/questions/14774053/intellij-diff-tool-in-sourcetree (bin path for me is
/Applications/RubyMine.app/Contents/MacOS/rubymine
) - Bookmark a temp repo that you use to grab PRs in SourceTree
- ???
- PROFIT!
"RefCountingStorage write content helper" prio=0 tid=0x0 nid=0x0 waiting on condition | |
java.lang.Thread.State: WAITING | |
on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@5b33ea53 | |
at sun.misc.Unsafe.park(Native Method) | |
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) | |
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) | |
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399) | |
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:957) | |
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:917) | |
at java.lang.Thread.run(Thread.java:680) |
"repositories": [ | |
{ | |
"type": "composer", | |
"url": "http://packages.firegento.com" | |
}, | |
{ | |
"type": "package", | |
"package": { | |
"name": "connect20/lib_google_checkout", | |
"version": "1.5.0.0", |
. | |
├── [2907877] composer.json | |
├── [2937290] composer.lock | |
├── [2316418] magento | |
│ ├── [2890782] LICENSE.html | |
│ ├── [2890783] LICENSE.txt | |
│ ├── [2890784] LICENSE_AFL.txt | |
│ ├── [2890785] RELEASE_NOTES.txt | |
│ ├── [2890786] api.php | |
│ ├── [2880927] app |
/** | |
* Example: incoming property name (e.g. from PHP) has square brackets, e.g. names[0][1] | |
* var property = names[0][1]; | |
* var value = { | |
* names: [ | |
* ['some', 'data', 'here'] | |
* ] | |
* } | |
* result: value == 'some' | |
* |
This document outlines the vision and scope for v2 of the API.
Ordered lists represent prioritized order. We recannot accomplish everything at once, and thus everything needs to be prioritized sooner or later. I choose sooner.
This document does not attempt to present a comprehensive record of all the changes that will be made, as those will be captured by stories in JIRA. Instead, it establishes the goals, principles, and patterns that we'll use to make the decisions about what needs to change.
It is a living document and will evolve as we discover new edge cases and outliers that weren't previously considered.
--- | |
title: PagerDuty Developer | |
layout: main | |
--- | |
<ul class="breadcrumb"> | |
<li> | |
<a href="/documentation/rest/">REST API</a> | |
</li> | |
<li style="list-style: none"> | |
<span class="divider">/</span> |
{ | |
"swagger": "2.0", | |
"info": { | |
"title": "PagerDuty API", | |
"description": "The PagerDuty API provides programmatic access to entities within a PagerDuty account. It is designed around [RESTful principles](https://en.wikipedia.org/wiki/Representational_state_transfer) with a path structure based on resources and their relationships.\n\nAll requests and responses are serialized in [JSON](https://en.wikipedia.org/wiki/JSON), including error responses.\n\nSchema are designed to be reusable across requests and across endpoints.\n\nMore sophisticated API clients should treat PagerDuty resources as unique objects keyed by the `id` field that can be used in any API request involving resources of that type.\n\nEvery resource contains a `type` field that identifies the schema it uses.\n\n## Rate limiting\n\nEach account and authentication mechanism is limited to the number of API requests it can make every minute. API requests that exceed the API rate limit will return an [HTTP status code](error_codes.html#http_res |
Approval is needed before shipping any change used by one or more wild clients or releasing the API for general availability. In other words, the API must be contracted.
If you are working on a prototype API, you may ship your code at will, but you acknowledge the following tradeoffs:
- you are responsible to make any and all code changes to satisfy the final approved proposal before general availability
- in other words, there will be additional churn
- you have communicated to any clients of the prototype API that their integration may break at any time
PagerDuty is thrilled to announce that the new version of our popular PagerDuty REST API is now available for everyone to use in beta!
We've been working hard on this version of the API for a while and are excited about the improvements in speed, consistency, and ease of use that API v2 delivers.
If you're a PagerDuty customer, you've already been using API v2 for a while every time you use our web application. In our own experience, we've found it easier to work with and build new functionality using API v2 than ever before.