Add blog-post about downtream workflow

content/docs/configuration.md

@@ -688,7 +688,7 @@ jobs:
       - epel-8
 ```
 
-##### bodhi\_update (coming soon)
+##### bodhi\_update
 
 Create a new update in
 [Fedora Bodhi](bodhi.fedoraproject.org) for successful
@@ -702,6 +702,8 @@ For now, the Bodhi update is created only for builds submitted by the Packit FAS
 This is just for the early stage of this job and
 we can easily turn off that filter.
 Let us know if you need this condition to be removed.
+Also, you need to give `commit` rights to `packit` FAS user
+for your package in dist-git settings.
 
 There is no UI provided by Packit for the job,
 but it is visible across Fedora systems

content/docs/guide.md

@@ -176,10 +176,10 @@ If you are looking for an inspiration for your .packit.yaml, check [packit's
 config file](https://github.com/packit/packit/blob/main/.packit.yaml)
 since we try to use all the latest features.
 
-## Packit service handles Fedora Rawhide updates for you.
+## Packit service handles Fedora updates for you.
 
 So you already have a `jobs` section in your config. Let's extend it with another
-job to push new upstream releases to Fedora rawhide.
+job to push new upstream releases to Fedora rawhide:
 
 ```yaml
 jobs:
@@ -191,8 +191,17 @@ jobs:
 ```
 
 Pretty clear I'd say: when a new upstream release happens, propose it to
-dist-git main branch: Fedora Rawhide. When running locally, you can set `create_pr`
-option to `false`:
+dist-git main branch: Fedora Rawhide.
+
+If you are wondering if you can use this for other branches as well,
+you will not be disappointed.
+That is exactly why there is a `dist_git_branches` key where you can specify the list of
+all the dist-git branches you want to update.
+And if you don't want to change the configuration every release,
+take a look at [aliases](/docs/configuration/#aliases) you can use instead of hardcoded versions.
+
+When running locally, you can set `create_pr` option to `false`
+to directly push to a dist-git branch:
 
 ```yaml
 create_pr: false
@@ -205,8 +214,37 @@ jobs:
 ```
 
 This option is ignored in Packit running on GitHub for security reasons and **is not**
-recommended either. Packit user in Fedora is not a proven packager, so you need
+recommended either.
+
+Here, CI systems and packagers need to step in and verify the proposed changes.
+
+Once the pull-request is merged, you can use a [`koji_build` job](/docs/configuration/#koji_build) to trigger the Koji build
+for new dist-git commits. It can be configured like this:
+
+```yaml
+jobs:
+- job: koji_build
+  trigger: commit
+  metadata:
+    dist_git_branches:
+      - fedora-all
+```
+
+And if you do not wish to wait for the successful build and create the Bodhi update yourself,
+just configure [another Packit job](/docs/configuration/#bodhi_update) to create it automatically:
+
+```yaml
+jobs:
+- job: bodhi_update
+  trigger: commit
+  metadata:
+    dist_git_branches:
+      - fedora-branched # rawhide updates are created automatically
+```
+
+
+Packit user in Fedora is not a proven packager, so you need
 to grant [packit user](https://src.fedoraproject.org/user/packit) the ability to push.
 
 And that's about it. Now you should be able to use the core features of the Packit.
-If you have any questions, feel free to reach out to us.
+If you have any questions, feel free to [reach out to us](https://packit.dev/#contact).

content/posts/downstream-automation.md

@@ -0,0 +1,138 @@
+---
+title: "Downstream automation is here"
+date: 2022-03-02
+weight: 68
+---
+
+# Downstream automation is here
+
+Finally, it's here. Now, you can do the whole Fedora release with the help of Packit.
+Let's take a look at how it works on an example of [OGR](https://github.com/packit/ogr), the Python library we develop.
+
+## Upstream
+
+The process of releasing a new version starts in the upstream repository.
+Here, we can see an upstream release:
+
+![Upstream release](/images/downstream_workflow_upstream_release.png)
+
+## Propose downstream
+
+As the first step on our way to Fedora users, we need to get the new upstream release to the Fedora dist-git.
+This is what we call `propose-downstream` job.
+Here is a snippet from the config file of OGR:
+
+```yaml
+downstream_package_name: python-ogr
+copy_upstream_release_description: true
+
+jobs:
+  - job: propose_downstream
+    trigger: release
+    metadata:
+      dist_git_branches:
+        - fedora-all
+        - epel-8
+```
+
+How does the `propose-downstream` work?
+As a first step, the archive is saved to lookaside cache
+and after that, Packit updates the dist-git content (mainly `sources` file and spec-file)
+via pull-requests for the specified branches. (Direct push is possible only for CLI by setting a
+[`create_pr` option](https://packit.dev/docs/configuration/#create_pr) to `false`.)
+
+If you use [`copy_upstream_release_description: true`](https://packit.dev/docs/configuration/#copy_upstream_release_description),
+as in the config above,
+the changelog entry will use the GitHub release description field.
+(Just make sure the formatting is compatible with spec-file.
+E.g. use `-` instead of `*` for lists to not create multiple changelog entries.)
+
+And how is it triggered?
+Packit gets the information about the newly created release from GitHub (via webhook),
+loads the config from the release commit and if there is a `propose-downstream` job
+defined, the workflow begins.
+
+Here are the pull-requests created by Packit:
+
+![List of downstream pull-requests created by Packit](/images/downstream_workflow_distgit_prs.png)
+
+And here are the details of the one created for `f35` branch:
+
+![Downstream pull-request created by Packit](/images/downstream_workflow_distgit_pr_detail.png)
+![Downstream pull-request created by Packit: changes in specfile](/images/downstream_workflow_distgit_pr_specfile.png)
+
+Now, it's on downstream CI systems and maintainer to check the changes and merge
+the pull-request.
+
+## Koji
+
+If Packit sees a new commit in the configured dist-git branch, it submits a new build in Koji
+like maintainers usually do. (The commits without any spec-file change are skipped.)
+
+![List of Koji builds triggered by Packit](/images/downstream_workflow_koji_builds.png)
+
+Here is a job definition for the package we use as an example:
+
+```yaml
+jobs:
+  - job: koji_build
+    trigger: commit
+    metadata:
+      dist_git_branches:
+        - fedora-all
+        - epel-8
+```
+
+There is no UI provided by Packit for the job,
+but it is visible across Fedora systems (like you can see in the following image)
+like a manually created Koji build and you can utilise
+[Fedora Notifications](https://apps.fedoraproject.org/notifications/about)
+to get informed about the builds.
+
+![Build status in merged downstream pull-request](/images/downstream_workflow_distgit_pr_build_status.png)
+
+## Bodhi
+
+Once Packit is informed (via fedora-messaging bus) about the successful Koji build,
+it creates a new update in Bodhi for you.
+
+![List of Bodhi updates created by Packit](/images/downstream_workflow_bodhi_updates.png)
+
+Here is a job definition:
+
+```yaml
+jobs:
+  - job: bodhi_update
+    trigger: commit
+    metadata:
+      dist_git_branches:
+        - fedora-branched # rawhide updates are created automatically
+        - epel-8
+```
+
+The packit config is loaded from the commit the build is triggered from.
+Just don't forget to give `commit` rights to `packit` FAS user
+for your package in dist-git settings so Packit can create the update for you.
+
+Here is an example of the resulting Bodhi update:
+
+![Bodhi update created by Packit](/images/downstream_workflow_bodhi_update_detail.png)
+
+And that's all. The rest is on the users and maintainers to give the update enough Karma
+so the update gets to the users.
+
+## Conclusion
+
+Does it look simple? Yes, it is. We try to automate
+as much as possible but still leave the space for human intervention where it is needed --
+pull-request review and verification of the Bodhi update.
+Of course, in case of some errors, a human can (and should)
+replace the work of a bot.
+Other manual, mundane and waiting tasks are replaced by Packit.
+
+Please, try it yourself and let us know what do you think.
+Those jobs are really new and some issues might occur.
+But we will try to fix those and if you have any suggestions
+for improvement, please, [create an issue]() so we can
+see if the request is doable and we can try to implement it.
+And of course, code contribution is more than welcome as well.