This commit unifies the behaviour of displaying no-builds and not-active
errors for repo and fixes the error when user can't access repo settings
when the project is not active.
Our mechanism for blacklisting IPs, which was developed as a protection
against a DDoS attach, sometimes classifies IPs as offenders
incorrectly. In order to temporary improve the situation of 403
responses from API we're now going to authenticate all of the ajax
calls, because authenticated calls are not blacklisted that easily.
Builds on repo model already incorporate all of the builds that belong
to a given repo and are loaded into a store, so no need to load them to
expandable array.
After recent refactorings status images popup started to fetch branches
info whenever a repo page was opened, resulting in additional HTTP
requests. Furthermore, because of a way we load branches, it could
result in builds view displaying very old builds, because in API V2 we
essentially download last build for each branch for branches request.
This commit fixes the situation in 2 ways:
1. We wait with downloading branhes till the popup is open
2. We use a V3 requests to download branches and we don't put that data
into the store
While a job is running, on the job status view, the duration is labeled: "Running for x sec". When the job finishes, 'Running' is swapped for 'Total time'. But "Total time for x sec" doesn't make any sense. the " for" should be part of the conditional with "Running"
When I changed tabs-list-view to be a component I missed the fact that
config is not registered for components, which resulted in not showing
the running jobs tab at all. This commit fixes the situation.
While fixing deprecations a `propertyBinding="foo"` calls were changed
into `property="foo"` calls, which should be `property=foo`. Otherwise
`foo` is treated as a string.
New ember-data serializers send data without a model key in the payload
by default, so instead of what API expects:
{
"hook": {
"id": 1,
"active": true
}
}
it would send:
{ "id": 1, "active": true }
Because of that we need to change how hooks are serialized.
Furthermore, API V2 returns just "result: true" after a successful
request to change a hook, so we need to return something meaningful from
the adapter's updateRecord in order to make ember-data happy.
`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.
