fedora-modularity / bpo

Build Pipeline Overview service for the Fedora Modularity project

#Build Pipeline Overview This is a service providing a single UI for accessing information about build states of modules. The first version (currently in progress) is an experimental proof-of-concept hackish implementation. Learn more about BPO

##Local Development

$ docker-compose up

You might need to wait 10 seconds for the bpo-updater-fake container to push some mock data into elasticsearch.

The UI will be available on http://localhost

Requires docker 1.10 and docker-compose 1.7

Resources in this repo

• Data structure in Elasticsearch

• Fedmsg messages associated with a module build

bpo's Issues

When build fails, show where it failed, not just generic "failed" message

Currently, when a build fails, the UI will no longer show the progress flowchart, but just generic "failed" message.

It should show in which step it failed.

This is currently because there is just a single state "failed" in fedmsg messages.

BPO: listen for component build state messages

As a module developer, I want to see the build states of components in my module, so I have more detail about the build process.

WHAT: bpo-updater-fedmsg needs to listen for messages from the build service (Koji, Copr) and update Elasticsearch accordingly.

Originally filed at https://trello.com/c/V2OKv0aq/590-bpo-listen-for-component-build-state-messages

Get rid of fake updater

I should get rid of the fake updater that puts data into Elasticsearch directly. Instead, I should use the fedmsg updater to listen to messages from the testing emitter - so the updater would get tested as well.

List of releases shows only 10 releases

It is probably because of a wrong Elasticsearch query.

BPO to support more complex "releases"

As a module developer, the user interface of "releases" in BPO is somewhat confusing as it implies an ordered history of builds as the only metadata regarding an instance of a module.

AC: BPO ui updated to reflect a change to builds

Originally filed downstream here: https://trello.com/c/ETCqc0kK/567-bpo-to-support-more-complex-releases

Display more modulemd information in the BPO.

This is copied from trello. Here's the original text:

• As a BPO user, I want to see components, API, and install profiles, so I know more details about the module.
• As a BPO dev, I need to have components, API, and install profiles in PDC, so I can ask for that info.
• AC: PDC stores components, API, and install profiles.

Would it be possible for BPO to get that information from the module build service? Or are we trying to avoid that? Perhaps PDC should have some sort of key or commit hash so that you can easily go look up the modulemd information in the MBS or in dist-git?

Add asamalik/BPO to github2fedmsg.

Adam, can you log in to https://apps.fedoraproject.org/github2fedmsg and enable fedmsg notifications for this BPO repo? I want to use them to sync BPO issues to our jira scrum board.