getsentry / zeus Goto Github PK

The API automatically responds to the need for upgraded permissions, but we should information the user of the action before redirecting them.

probably also should have a 'artifacts pending processing' stage

Should automatically fetch/create (if possible) and continue to reject when not.

I enabled sentry-php and was only granted member permissions until I logged back in

Would love to see this work with CircleCI too.

We want to be able to support public projects/repos. We will still require authentication.

This means:

• Default the project to state on GitHub (but persist it as the default, so if the 'default' changes we simply change)
• Allow the project to opt-in/out of public via settings

This is going to be a bit complicated with tenants.

lets see if we cant replace everything with graphql so we can query the appropriate data

https://github.com/graphql-python/graphene-sqlalchemy

we need to stream updates into the UI for things like build state changes

could possibly use sanic for this + event source

note: event source doesnt seem to work in edge yet, but idc

It's all there on the backend, so we just need to do some work in the UI and the provider abstraction.

Likely will wait to do this until we finish the Travis integration, as the jsonschema/config stuff there should carry over nicely into the VCS provider abstractions.

https://sentry.io/sentry/zeus/issues/333448484/

IntegrityError: null value in column "email" violates not-null constraint
DETAIL:  Failing row contains (905111c2-877f-11e7-8f15-0a580a2804b4, null, 2017-08-22 21:19:20.991802+00).

  File "sqlalchemy/engine/default.py", line 470, in do_execute
    cursor.execute(statement, parameters)
  File "sqlalchemy/engine/base.py", line 1182, in _execute_context
    context)

IntegrityError: (psycopg2.IntegrityError) null value in column "email" violates not-null constraint
DETAIL:  Failing row contains (905111c2-877f-11e7-8f15-0a580a2804b4, null, 2017-08-22 21:19:20.991802+00).
 [SQL: 'INSERT INTO "user" (email, id, date_created) VALUES (%(email)s, %(id)s, %(date_created)s)'] [parameters: {'email': None, 'id': UUID('905111c2-877f-11e7-8f15-0a580a2804b4'), 'date_created': datetime.datetime(2017, 8, 22, 21, 19, 20, 991802, tzinfo=datetime.timezone.utc)}]
  File "sqlalchemy/engine/default.py", line 470, in do_execute
    cursor.execute(statement, parameters)
  File "sqlalchemy/engine/base.py", line 1182, in _execute_context
    context)
  File "sqlalchemy/util/compat.py", line 186, in reraise
    raise value.with_traceback(tb)
  File "sqlalchemy/util/compat.py", line 203, in raise_from_cause
    reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File "sqlalchemy/engine/base.py", line 1402, in _handle_dbapi_exception
    exc_info
...
(20 additional frame(s) were not displayed)

AttributeError: 'NoneType' object has no attribute 'config'
  File "zeus/web/views/auth_github.py", line 96, in get
    identity.config = identity_config
...
(4 additional frame(s) were not displayed)

AttributeError: 'NoneType' object has no attribute 'config'

Now that we've got a semi functional stream we need to:

• Implement channels on the backend
• Propagate changes correctly into the UI (some endpoints are already setup to filter correctly)

Using this ticket to document some UI things. @ckj has already landed some skeleton, though I think we'll have to rethink the "list of builds" view as it likely needs to be full width.

High level of what we want:

• Repository list
  • % line coverage
  • duration
  • total tests
  • latest build result
• Build list
  • % diff coverage
  • duration
  • total tests
  • delta of tests
  • result etc

Here is the current pass @ckj landed:

What we likely want is a build/repo view similar to changes, and then a drastically overhauled build details view. The core goal of the build list is to understand how quality is changing at a glance. The goal of the build details is to understand the result, and quick access to reports (coverage, tests, screenshots).

Before we can start implementing the UI, we need:

• finished data model (its actually in a good enough state right now)
• ability to quickly load mock data

Here are a few snaps from Changes:

List of Builds

List of Commits

Build Details

I want to take this for a spin, but readme indicates travis-ci.com is not yet supported.

Is that on the roadmap for any time soon? What's theoretically involved in adding that support? Is there an in-the-meantime workaround that wouldn't require hosting Zeus myself?

We can likely pass this as part of the artifact upload, since we'd want to report different style of JUnit tests to the same repo.

You can see an example of this being bad/broken within Zeus' JS tests.

Rough idea of what im thinking for ACLs:

• Sign in via GitHub
• Fetch a list of repositories you can access
• "Add" a repository per the list
• Install ssh key on each repo when its added for the first time

TBD: How do we continually grant/revoke access per repository?

Either way, we're using the same repository model as Changes, and can support non-GitHub/etc.

Let's add support for status checks, which is the next step to removing N third party dependencies on "is the build green".

https://developer.github.com/v3/repos/statuses/

This is specifically with Travis hooks.

https://zeus.ci/gh/getsentry/zeus/builds/524

We need secondary email addresses for mapping up commit authors. GitHub fortunately let's us pull those in as part of the integration, so we should automatically sync those and their verified state (verification is required).

we need to decide what to do when a job is retried

simplest/most accurate answer would be to orphan the job (or just straight up delete it), and create new rows for it. if we orphaned it we could still track its visibility and build, but it wouldn't show up in the UI, and its build number would need reclaimed

Given that we can't allow '/' in repo names, we're going to add native org/project support (projects the same as changes).

We need an easy to use/understand system for doing object permissions in the API.

Right now its up to the base class to do this, but its kind of a mess. Likely this looks like this:

class Permission(object):
    config = {'GET': Permission.read}
   
    def has(self, obj, tenant, permission):
        raise NotImplementedError

class HookPermission(Permission):
    config = {'GET': Permission.admin}

PERMISSION_REGISTRY[Hook] = HookPermission

    def check_permission(self, obj):
        permission_cls = PERMISSION_REGISTRY.get(type(obj))
        if not permission_cls:
            return True

        tenant = auth.get_current_tenant()
        required_permission = self.permission_overrides.get(
            request.method, permission_cls.config[request.method]
        )
        return permission_cls().has(hook, tenant, required_permission):

right now the constraint is (job_id, filename)- we need coverage to be (build_id, filename), as we dont want to track duplicate coverage at the job level and have to merge them

We dont want to keep them forever. Can do something like 30 days as an easy stop gap.

This is a little bit hitting undo on what we did previously, but lets find a good pattern to split permissions.

We'd like three things:

1. "Login via GitHub", which requires no repo permissions (user:email,read:org)
2. "Allow public repos" (public_repo)
3. "Allow private repos" (repo)

The problem we had before was reauthorizing GitHub seemed to clear the previous scopes we had requested. There must be a way to avoid that, otherwise we'll have to reauthenticate each time a user wants to add a new repo.

Long lists like tests or coverage reports can easily get confusing. It would be great to have a tree view just like in file browsers, to collapse layers and view aggregated data on parent nodes.

• Group tests by folder and file name or class name
• Group coverage by folder
• Group artifacts by type (if there are many artifacts and shared types)

https://sentry.io/share/issue/8d2216660cb943c1b4b7c2712342bc70/

Error: Repository not found or you do not have access
  at ExtendableBuiltin (/usr/src/zeus/js/app.a34ab85d.js:863:608)
  at new t (/usr/src/zeus/js/app.a34ab85d.js:863:2873)
  at getDefaultState (/usr/src/zeus/webapp/pages/RepositoryDetails.jsx:36:13)
  at AsyncPage (/usr/src/zeus/webapp/components/AsyncPage.jsx:21:23)
  at new t (/usr/src/zeus/js/app.a34ab85d.js:18120:3060)
...
(18 additional frame(s) were not displayed)

When you retry jobs in Travis (after a build is complete), it does not correctly update the build as 'in progress' and 'unknown result'.

Equiv to Changes. Parse standard coverage.xml (e.g. python's coverage tool)

Our Travis provider could automatically create secure environment variables so the users don't have to do that manually:

• ZEUS_HOOK_BASE: Currently used for artifact upload, might become unnecessary with #50
• ZEUS_TOKEN: Repository token (zeus-r-<hash>) that only grants access to this repo

See https://docs.travis-ci.com/api/#settings:-environment-variables.

However, the repository must be enabled in travis at that time already. I've found no documented way to do this via the API, but the travis command line tool can do that.

We require SSH keys for repos, and just because you can view a repo doesn't mean you can toggle to enable it.

https://sentry.io/sentry/zeus/issues/362309093/

HTTPError: 404 Client Error: Not Found for url: https://api.github.com/repos/redacted/keys
  File "requests/models.py", line 937, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
  File "zeus/utils/github.py", line 64, in _dispatch
    resp.raise_for_status()

ApiError: {"message":"Not Found","documentation_url":"https://developer.github.com/v3/repos/keys/#add-a-new-deploy-key"}
  File "zeus/utils/github.py", line 66, in _dispatch
    raise ApiError.from_response(e.response)
  File "zeus/utils/github.py", line 78, in dispatch
    return self._dispatch(method=method, path=path, headers=headers, json=json, params=params)
  File "zeus/vcs/providers/github.py", line 89, in add_key
    'read_only': True,
  File "zeus/api/resources/github_repositories.py", line 134, in post
    key=key,
  File "zeus/api/resources/base.py", line 64, in dispatch_request
    resp = method(*args, **kwargs)

failed to handle api request

We need a simple no-dependency binary that can run on (at least) mac/linux.

It will be responsible for:

• pushing artifacts to one or more endpoints (TBD)
• reporting build result/core metadata

It's possible this alone wont be enough and e.g. we'll need a dedicated endpoint for something like Travis.

More or less equiv to what Changes did, parse xunit reports or allow test result capture via direct API.

Its possible to e.g. upload multiple code coverage files if you retry a job in Travis, and this then duplicates results in the db.

Rough plan:

1. Implement listeners for 'status' hooks from GitHub
2. When status hook includes anything related to Travis, use keys to pull data (vs push?)
3. When pushing data, ensure we maintain data
4. Artifacts still need pushed
5. TBD: determine if artifacts should be present or not (do we wait for them vs marking the build as finished)

https://developer.github.com/v3/activity/events/types/#statusevent

In order to use Zeus for sentry-cli we need AppVeyor support. Besides feature parity with the current Travis provider, it would be great to see a more automated setup of environment variables. Also, zeus-cli might need a few updates.

Resources:

• API Documentation
• Webhooks Documentation

right now its only showing files found in the coverage report

it should also show n/a for files which are missing from the report, and not show at all if theres no report

Hi peeps!

I tried to access https://zeus.ci/login?next=%2Fbuilds but got 500:

The exception Zeus reported was:

TypeError: Cannot read property 'map' of undefined
    at Function.t.a.Object.loadBuildsForUser [as mapToProps] (https://zeus.ci/static/bundle.js:1:1209521)
    at r (https://zeus.ci/static/bundle.js:1:226744)
    at Function.r.mapToProps (https://zeus.ci/static/bundle.js:1:226863)
    at r (https://zeus.ci/static/bundle.js:1:226726)
    at o (https://zeus.ci/static/bundle.js:1:509021)
    at https://zeus.ci/static/bundle.js:1:509519
    at Object.run (https://zeus.ci/static/bundle.js:1:220513)
    at u.initSelector (https://zeus.ci/static/bundle.js:1:223050)
    at new u (https://zeus.ci/static/bundle.js:1:221953)
    at constructClassInstance (https://zeus.ci/static/bundle.js:1:407946)
    at beginWork (https://zeus.ci/static/bundle.js:1:411500)
    at o (https://zeus.ci/static/bundle.js:1:423836)
    at c (https://zeus.ci/static/bundle.js:1:424352)
    at u (https://zeus.ci/static/bundle.js:1:424827)
    at g (https://zeus.ci/static/bundle.js:1:426849)
    at m (https://zeus.ci/static/bundle.js:1:426358)
    at Object.enqueueSetState (https://zeus.ci/static/bundle.js:1:407628)
    at u.a.setState (https://zeus.ci/static/bundle.js:1:364262)
    at u.onStateChange (https://zeus.ci/static/bundle.js:1:223491)
    at Object.notify (https://zeus.ci/static/bundle.js:1:500277)
    at e.notifyNestedSubs (https://zeus.ci/static/bundle.js:1:500780)
    at u.onStateChange (https://zeus.ci/static/bundle.js:1:223509)
    at u (https://zeus.ci/static/bundle.js:1:225193)
    at https://zeus.ci/static/bundle.js:1:1218171
    at https://zeus.ci/static/bundle.js:1:1211829
    at dispatch (https://zeus.ci/static/bundle.js:1:507722)
    at https://zeus.ci/static/bundle.js:1:227986
    at <anonymous>

Let's rethink patches, and create a native concept for "Change Requests". These will power a few things:

• Pull Requests (GitHub) and status checks
• Diffs (Phabricator)

They'll become a top level concern, where effectively builds become either associated with a Change Request or a Commit (unrelated to "why" its being built).

https://zeus.ci/getsentry/zeus/builds/4
https://zeus.ci/getsentry/zeus/builds/5

haven't investigated, but seems like it shouldn't have happened

Right now when there's a selenium failure, we sometimes get a failing unit test, but we always get a resulting artifact.

It would be useful, at the very least, to show artifacts bundled as part of each job (maybe click to expand) on the overview. We could replace the artifact list with this (not on the dedicated tab).

On the dedicated tab we should annotate with which job its from.

Additionally, it probably makes sense at this stage to pull out a dedicated test details page, both per build and per project.

• Per project should include test history (e.g. flakiness)
• Per build should additionally include relevant artifacts to that job, since they could be related to the failure

Will simplify build hooks/various scripts

Currently we use Zeus hook URLs to upload artifacts. It would be much better to use the API for this. We already have user-based and repository-based tokens which can be used for authorization.

The current endpoint also does not include the provider id and might potentially collide on external ids. For now, this will not happen as Travis and AppVeyor use different ID schemas.

Ideally, we'd split the current endpoint in two requests:

1. Obtain the job by external build and job ID:
   GET /api/repos/provider/<p>/<o>/<r>/jobs?build_xid=<BUILD_ID>&job_xid=<JOB_ID>
2. Push an artifact to the job:
   POST /api/repos/provider/<p>/<o>/<r>/builds/<b>/jobs/<j>/artifacts

Both requests require bearer authorization. The CLI would obtain a token from ZEUS_TOKEN and then run both requests in sequence.

We need to allow users to disconnect a repository, which should then unregister any hooks or keys associated with it.

Disconnecting a repository will do so for all members of the organization.

Is that completely out of the scope of Zeus, or a possibility ?
The default jenkins UI is not great, I wonder how Zeus will help with that.

Hit something like https://localhost:8080/gh/foo/bar when you're not authenticated, and you'll get redirected to /login but it will show the 404 page.

We need to figure out how to handle the recovery from component errors, given this is happening from two API requests (one 404, and one 401).

if X enables a repo and Y also has access, they need to automatically gain access in various situations

• on login
• on repo sync (via cache)
• background task? (we also want this to explicitly revoke access)