Similar to #25, failed builds should be filed as an issue in the repo's GitHub tracker with a dump of the log.

what it says on the tin

Once we've determined that there exists an app, we should grab the app's actual name (not just the raw repo name) and display that in the import

On firefox the Button Positions are off by quite a bit, not sure what exactly is causing it:

left = chrome
right = firefox

I get GitHub error 401 on GET https://api.github.com/user/repos: Bad credentials when running npm start. @aroman says it requires clearing mongodb.

Add Deploy keys to private repos automatically so we can pull them down to the build farm.

It would be neato to pull in app icons from apps that are in the store on the main hero image and make some kind of collage.

At the moment Houston doesn't update if the changelog is changed on GitHub

We want devs to be able to give us a suggested price we can use as the default for AppCenter. I think immediately after you choose a repo makes sense here.

If releases.items is null, we should give a needs fixing status instead of offering to Publish. I'm pretty sure that a changelog is mandatory for debian packages.

Having the newest item on top in the debian changelog is important, we need to reverse it again, looking at you @aroman 😛

Our current error page looks like crap, so we really should add a nicer one

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I just went to http://server2.elementaryos.org:3000/ and tried to import a random project on my account.

Got this:

Cannot call method 'findOrCreateGitHub' of undefined
TypeError: Cannot call method 'findOrCreateGitHub' of undefined
    at Object.app.get.Project.findOrCreateGitHub.then.res.render.project [as handle] (/home/fabian/houston/houston/app/project.js:8:11)
    at next_layer (/home/fabian/houston/houston/node_modules/express/lib/router/route.js:103:13)
    at Object.module.exports.loggedIn [as handle] (/home/fabian/houston/houston/app/auth.js:62:41)
    at next_layer (/home/fabian/houston/houston/node_modules/express/lib/router/route.js:103:13)
    at Route.dispatch (/home/fabian/houston/houston/node_modules/express/lib/router/route.js:107:5)
    at /home/fabian/houston/houston/node_modules/express/lib/router/index.js:205:24
    at param (/home/fabian/houston/houston/node_modules/express/lib/router/index.js:286:14)
    at param (/home/fabian/houston/houston/node_modules/express/lib/router/index.js:298:16)
    at param (/home/fabian/houston/houston/node_modules/express/lib/router/index.js:298:16)
    at Function.proto.process_params (/home/fabian/houston/houston/node_modules/express/lib/router/index.js:314:3)

Can't currently log out/de-auth

that's #3A416F.

when adding a repository, we should check if this label exists and and create it if not

Before we start making a bunch of tests for projects, we should setup a nice way of keeping them organized, instead of placing them all into model files. Right now I'm thinking of some sort of hook style system where you would have a file like desktop.js that would register different errors and warnings. Then when a repo is pulled, houston would call all these files to test the code, build app, more tests, human review, and file the issue.

Some things to consider:
Tests should be able to run in parallel for the most part
Post-build tests
tests vs houston information (apphub file)
keep tests modular (add more tests with no houston code touched)
optional tests? (is this a thing?)

I'm thinking the way to do this is add an issues array field to ApplicationSchema, where each issue is its own IssueSchema which looks like this:

// IssueSchema
{
    githubId: 123, // e.g. github.com/user/app/issues/123
    body, // the actual content of the issue, e.g. automated output
    title, // the title of the issue, e.g. "Missing .desktop file"
}

Houston will file failed builds as issues, we need to establish a template for that, let's do it on github to see what it looks like:

Title:

[Apphub] 3 Issues detected on Release vX.X.X

Issue Body:

Apphub detected the following issues on Release vX.X.X

• Build of trusty-amd64 failed Build Log
• You are missing a .desktop file Learn More
• Some more random stuff

Once these issues have been resolved, please do a new Release and try publishing your Application [again](link to Houston Daskboard).

The idea is that packages are automatically built into a testing repo and then we have a human test and approve them to go into the stable repo. We'll need some kind of review queue page that:

• Can only be accessed by members of the houston app reviewers github team
• Lists packages that haven't yet been reviewed for that version/git tag
• Allows the reviewer to approve and upon approval copies the package into stable
• Allows the reviewer to reject and supply a reason why it was rejected which is filed as an issue

Something to consider is whether rejecting should always delete the package from testing or if we should provide some other mechanism for deleting. I'm thinking of a case where the reason the package is rejected it because it is malicious or otherwise dangerous to install.

Like npm start instead of ./server. And anything else that's changed. ;)

Doing some programming and having 11 or so issues on a project slowed dashboard load times quite a bit. We should try looking at some options for making it faster, as it's only going to get slower the more stuff we add to it.

First thing that comes to mind would be to create a separate projects page. One extra click for the user, but considerably less logic for us, as we don't have to load everything for every project on the dashboard at once.

WIth 3 projects, and a total of 14 issues the dashboard takes 2.77 seconds to load

We should set up a template project for devs to fork with everything in the right directories.

all the yellow stuff should be red (like "var")

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Trigger builds in Jenkins over the Jenkins API

If I remember correctly, you are planning to use freight to build the Debian repositories. Have you already seen aptly, which seems more active and also had a REST API which lets you...

upload packages using HTTP, manage your repositories, snapshots, published repositories etc.

This might better suite your needs, since you need to interface the repo anyway.

We need to hook up status into the Houston UI. Avi thought the way to do this is with handlebars instead of setting classes.

It would be very nice, if you could provide a bigger picture of how things are (or should be) looking like and what part of the system is responsible for what.
How are the builds triggered, how and where are the builds performed, where are the information for the build process coming from, where are the deb packages pushed to, aso. Thanks!

Looks kind funny that they are all just randomly aligned. I think it'd be nice if they right aligned.

We should define some kind of litmus test to decide whether or not a repository is an app and if not, don't show it.

I think probably the defining test is whether the repo contains a .desktop. Specifically it might be most performant to just look for /data/.desktop

s/'{{owner}}/{{repoName}}'/{{repo.fullName}}

The secondary text in the dashboard should link to the page on GitHub

It looks like what happens is some child of the anchor is what is receiving the event (specifically i) and so the active class is given to its parent instead of to the popover. So I guess we have to make sure that children of the anchor don't receive events.

It seems like not long from now we're going to want to have a couple of beta testers to work though some of the issues in actual use. We're going to need some kind of whitelist mechanism to restrict access for requesting builds on our instance of houston

Going with the "GitHub is the UI" idea, we should just use GitHub Issues for review failures. If an app fails an automated test, Houston should file a bug in that repository's issue tracker.

We should grab the app icon by parsing the .desktop and then getting it from /data/icons/[size]/*.[img extenstion] and if we can't find it, just show the default app icon

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Add the webhook automatically so we get updates on repos that are set up with houston.

I see value in keeping the dumps around for now, but let's put them in an HTML comment so they don't junk up the UI.

An empty .elementary in the root of the repo is how houston knows which apps to look at.

should be

An empty .apphub in the root of the repo is how houston knows which apps to look at.

Show an error & helpful steps to fix it when we are missing an icon and/or .desktop file.

We need cody to setup liftoff on the jenkins server so we can actually build projects.

Not sure it really makes sense to show the user avatar here. If we can't get the app icon, we probably want to indicate that with the generic icon

When we build a package into the debian repo, we need to run the dep11 script to update the appstream metadata for that repo https://github.com/ximion/appstream-dep11

Just found out about "appstream-util validate" command. We should make a test with that

Process webhooks and watch for these things:

• New Tags/Releases on Github
• New commits on a defined branch (for daily)

Our app store is AppShop. We need to change any references.

We need to pull in the release notes and version number to verify what we're publishing