Deprecate production_build in favour of upstream_koji_build

content/docs/Configuration/_index.md

@@ -496,7 +496,9 @@ Additionally, `epel-all` can be used as an alias for the current active
 
 The aliases above can be used both to specify targets when [building in
 Copr](#copr_build) or [running tests](/testing-farm/), and to reference
-[dist-git branches](#production_build) of different system versions.
+dist-git branches of different system versions
+(e.g. for [`propose_downstream` job](#propose_downstream)
+or downstream jobs like [`koji_build](#koji_build) or [`bodhi_update`](#bodhi_update)).
 
 The information about releases is retrieved from Bodhi and because of the
 cache and required availability on Copr, it might take a while to get the
@@ -613,7 +615,7 @@ fedora-32-armhfp
 
 See more about tests [here](/testing-farm/).
 
-##### production\_build
+##### upstream_koji_build
 
 Create a SRPM from upstream and submit a scratch RPM build
 to [Fedora Koji](https://koji.fedoraproject.org/koji/) build system.
@@ -623,8 +625,9 @@ For more info, please see [the following issue](https://pagure.io/releng/issue/9
 
 If you want to do official Koji builds, the sources need to be present in
 dist-git: job [`koji_build`]({{< ref "#koji_build" >}}) can take care of that.
-(The naming is not ideal, but we don't want to change this because of the
-backwards compatibility.)
+
+(The job used to be called `production_build` but we are deprecating that name in favour of
+the more explicit `upstream_koji_build`.)
 
 Supported triggers:
 
@@ -694,8 +697,7 @@ like a manually created Koji build, and you can utilise
 [Fedora Notifications](https://apps.fedoraproject.org/notifications/about)
 to get informed about the builds.
 
-For Koji builds from upstream, see [`production_build`](#production_build).
-(The naming is not ideal, but we don't want to change this because of the backwards compatibility.)
+For Koji builds from upstream, see [`upstream_koji_build`](#upstream_koji_build).
 
 Supported triggers:
 

content/docs/faq.md

@@ -14,7 +14,7 @@ service, your repository or namespace needs to be allowed.
 Just be aware that we are now onboarding Fedora contributors who have
 a valid [Fedora Account System](https://fedoraproject.org/wiki/Account_System) account.
 For more details on how to get allowed for our service, please read
-the requirements [here](/docs/packit-service#requirements-for-running-packit-service-jobs).
+about the process [here](/docs/guide/#2-approval).
 
 ## Can I use packit service for any GitHub repository?
 
@@ -59,7 +59,7 @@ Packit connects the existing services ([Copr](https://copr.fedorainfracloud.org)
 
 ## Can we use Packit with Gitlab?
 
-Yes! You can find instructions at the [Packit Service page](/docs/packit-service#gitlab).
+Yes! You can find instructions at the [Packit Service page](/docs/guide#gitlab).
 
 ## How can I download RPM spec file if it is not part of upstream repository?
 

content/docs/fedora-releases-guide.md

@@ -15,7 +15,8 @@ Doing Fedora releases with Packit means utilising our 3 jobs - `propose_downstre
 `bodhi_update` - where each of the jobs takes care of a different part of the release process.
 
 ## Propose downstream job
-For enabling the propose downstream job, you need to have [Packit Service installed](/docs/packit-service) 
+For enabling the propose downstream job, you need to have
+[Packit Service installed](/docs/guide/#1-set-up-packit-integration)
 and have a `propose_downstream` job in the configuration file for the given upstream repository.
 The [propose_downstream job](/docs/configuration/#propose_downstream) should be then configured like this:
 

content/docs/guide.md

@@ -271,7 +271,7 @@ hardcoded values that changes when there is a new distribution release.
   or to provide long-term Copr repositories.)
 * [`tests`](/docs/configuration/#tests): Test suit using TMT/FMF definition run in the [Testing Farm](TBD)
   (Can be used as a next step to Copr build or without build at all.)
-* [`production_build`](/docs/configuration/#production_build): A scratch Koji build triggered for the upstream state of project.
+* [`upstream_koji_build`](/docs/configuration/#upstream_koji_build): A scratch Koji build triggered for the upstream state of project.
 * [`propose_downstream`](/docs/configuration/#propose_downstream): For upstream release, Packit prepares a Fedora release.
   (Source is saved to the Lookaside Cache and a dist-git pull-request is created for each configured branch.)
 * [`koji_build`](/docs/configuration/#koji_build): A downstream Koji build triggered when there is a new dist-git commit in a given branch.

content/posts/fas-verification-automation.md

@@ -5,7 +5,7 @@ weight: 94
 ---
 
 As you may already know, for using Packit Service
-GitHub App we [require our users to have a valid Fedora Account System account](/docs/packit-service/#requirements-for-running-packit-service-jobs).
+GitHub App we [require our users to have a valid Fedora Account System account](/docs/guide/#2-approval).
 We were verifying the newcomers until now manually, but in recent weeks, we have implemented an automated solution
 for it. Let's take a closer look at how it is done currently and what have we improved!
 

content/posts/fedora-eln.md

@@ -24,7 +24,7 @@ Oh, wait!
 ### You can do this easily with Packit
 
 If your GitHub project is not using Packit yet, [here's a
-guide](https://packit.dev/docs/packit-service) how to start.
+guide](https://packit.dev/docs/guide) how to start.
 
 Once it's set up, you need to make sure that your pull requests are also being
 built in the `fedora-eln` target:

content/posts/weekly/May-2022.md

@@ -40,7 +40,7 @@ weight: 62
 - Resolved an SRPM build problem caused by a new version of git that refuses to fetch in a git repo when it's owned on the OS level by someone else. ([packit#1497](https://github.com/packit/packit-service/pull/1497))
 - Packit now passes `PACKIT_COPR_PROJECT` and `PACKIT_COPR_RPMS` variables to the Testing Farm. `PACKIT_COPR_PROJECT` holds Copr project in format owner/project and `PACKIT_COPR_RPMS` space-separated RPMs that were built in Copr. ([packit-service#1486](https://github.com/packit/packit-service/pull/1486))
 - Packit now builds only its own dist-git commits. Other commits are not being acted upon. For reasoning, see [packit-service#1490](https://github.com/packit/packit-service/issues/1490). ([packit-service#1498](https://github.com/packit/packit-service/pull/1498))
-- We have automated our allowlisting process via a new Packit comment command `/packit verify-fas`. You can find more info in [our requirements](https://packit.dev/docs/packit-service/#requirements-for-running-packit-service-jobs). ([packit-service#1487](https://github.com/packit/packit-service/pull/1487))
+- We have automated our allowlisting process via a new Packit comment command `/packit verify-fas`. You can find more info in [our requirements](https://packit.dev/docs/guide/#2-approval). ([packit-service#1487](https://github.com/packit/packit-service/pull/1487))
 
 ## Week 20 (May 17th - May 23rd)