Flatpak Build Service Workflows Example

Robert is an application developer of GNOME Twitch, a twitch client. He uses Builder for development and stores his code on GitHub. He wants to distribute new versions of his application rapidly, and Flatpak looks like a good option.

1. He starts by creating an account. It asks for his name, e-mail address and password.
2. The website prompts him to create an app, so he does gives it a name
3. Then he's prompted to create a branch; the website explains that he should create a Git repository containing his build configuration. He does this on GitHub (since he's using it already) and then creates the branch, enters the URL for the repository and sticking with the suggested branch name of "master". . At this point there are other options for the branch, but Robert ignores them for now.
4. Now that he has a branch, Robert sees that he can start a build, which he does.
5. He sees that the build get queued. (will he get a time estimation?)
6. He closes the Flathub tab in his browser.
7. A while later he gets an e-mail that the build is done. . Allan Day: Or he gets a notification from Builder? Need to think about how this integration would work. Email maybe isn't the best solution for this - builds are repeated frequently, and hopefully shouldn't take too long.
8. He downloads and tests the build on his local machine, using the branch URL from the website.

Robert has been using Flathub for a while, and wants to publish his app on the Flatpak Store.

1. He selects the latest successful build, which is the one he wants to publish, and presses the publish button
2. He fills in some details about who he is - that he is the GNOME Twitch maintainer, and links to the GNOME Twitch homepage.
3. Feedback is shown that verifies that GNOME Twitch has passed automatic tests. A message says that he'll hear back once his application has been reviewed.
4. Jorge, a Flatpak Store administrator, receives an email saying that an app is waiting to be reviewed. He clicks on the link and is taken to a review page.
5. Jorge tries the app and checks Robert's identity. He then approves it and posts it to the store.
6. Robert receives an email informing him that his app has been published. It contains a link to a FlatHub page that shows him information about GNOME Twitch's status in the store.

Jeff is a codeveloper of Robert, but Robert is the maintainer. Robert wants to add Jeff to the organization, so that he can upload changes and trigger builds. He doesn't want Jeff to do releases though.

1. Jeff creates an account on Flathub. Fills out name, e-mail address and password.
2. He tells Robert to add him to his organization.
3. Robert logs in, adds Jeff, and sets the permissions to allow Jeff to build but not to publish.
4. Jeff gets a mail that he was added to the organization.
5. He is now able to trigger builds, so he uploads a new version, and it gets built.
6. Robert logs in, download and test the build that Jeff did.
7. It works fine, so he releases it.

Peter really like watching Magic Tournaments over Twitch.

1. He looks for a app in the software center on his OS.
2. Finds GNOME Twitch and installs it.
3. Two days later, he gets the update that Jeff built and Robert released.