`lastBuild` is a synchronous relationship on a branch model, so we need to
have a build record present when we put a default branch from a repository
model into the store. We don't send lastBuild's payload in pusher, so
we need to get it using an ajax call, if it's not already in the store.
In the future we may decide to make the relationship async, but I don't
want to change the code at the moment
Removed code was checking if we should handle a pusher event, ie. if the
event is associated with the user, or if we already have a record
associated with the event. We don't need the check now, because we no
longer use the common channel.
In a repo route we need to find record by slug there is no easy way to
do it with a public finders API, so we need to use adapter and
serializers directly. The problem is that the old way of doing this
didn't use the normalizePayload function and also it didn't add included
records properly. New code properly normalizes response and adds all of
the embedded records that were extracted from the response.
This commit fixes handling of branches when using both V3 and V2. The
changes include:
* proper definition of relationships that reflect V3 structure, so for
example build belongs to a branch
* setting up inverse records for some of the relationships. without
doing that Ember Data can handle relationships in a surprising way,
for example if the same record is referenced in 2 places in a
belongsTo relationship, Ember Data will remove one of the references
without proper inverse definitions
* we need to add id when extracting branch as a relationship. Ember
Data expects all of the relationships to have an id
* lastly, we need to mimic the structure of the V3 API in V2 payloads,
so for a build payload I'm now creating a branch record
V3 API doesn't return any of the records more than 2 times. If a record
is already included in the response any other occurences will be
represented as a reference, ie. a hash with just an @href. Ember Data
doesn't play nice with such references as it needs an id to identify a
record.
The code in this commit traverses payloads from V3 API and adds an id to
each of the references that are present.
For example a following payload:
{
"@href": "/build/1",
"@type": "build"
"id": 1,
"state": "passed",
"branch": {
"@href": "/repo/1/branch/master",
"name": "master",
"lastBuild": {
"@href": "/build/1"
}
}
}
Will be changed to:
{
"@href": "/build/1",
"@type": "build"
"id": 1,
"state": "passed",
"branch": {
"@href": "/repo/1/branch/master",
"name": "master",
"lastBuild": {
"@href": "/build/1",
"id": 1
}
}
}
In this case an "id" field was added to "branch.lastBuild" field.
This commit just fixes things to the point where pusher updates are
applied to the store properly. This still lacks a business logic fixes,
so for example we won't update lastBuild's field, because there's no
such information from pusher.
* we should look for both embedded relationship and relationship key,
so in cases like for commit, when there's a full commit data on
"commit" property, and only id at "commit_id", we will use commit data
* we can't add @type to V2 fallback, because in other places we chack
for @type to distinguish V2 and V3 payloads
* there's no need to include a record in "included" if there's only a
type and an id there
For some reason (probably some problem with one of the serializers) we
sometimes lack an id attribute for a promise that we get for a repo
relationship on build. Because of that doing `build.get('repo.id')` may
sometimes return undefined. A temporary workaround is to make sure that
we always can access the `repository_id` property.
Since we change repos property on reposController, we can't set observer
on repos, because as soon as it's changed, we loose the observer.
Instead, we should observe only on reposController, which is not going
to change.
One thing that is not standard here is a serializer for branch, which
uses @href as id. At this point branches don't have ids and ember-data
needs one, so using @href is the easiest way.
This commit adds adapters and serializers for v3, but also a fallback
serializer for v2, which allows to handle v2 and v3 payloads at the same
time. This is needed, because when we use v3 endpoint for one of the
models (in this case repo), we can also get embedded records of other
types (like branch or build).
