diff --git a/content/docs/Configuration/_index.md b/content/docs/Configuration/_index.md index b1145b15e1..16fdc5c9b9 100644 --- a/content/docs/Configuration/_index.md +++ b/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: diff --git a/content/docs/faq.md b/content/docs/faq.md index 22cbf8403a..36e55025ac 100644 --- a/content/docs/faq.md +++ b/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? diff --git a/content/docs/fedora-releases-guide.md b/content/docs/fedora-releases-guide.md index 6fdbf0331b..b00aa4110e 100644 --- a/content/docs/fedora-releases-guide.md +++ b/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: diff --git a/content/docs/guide.md b/content/docs/guide.md index d488338f2f..a7fe9be199 100644 --- a/content/docs/guide.md +++ b/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. diff --git a/content/posts/fas-verification-automation.md b/content/posts/fas-verification-automation.md index 2e13379bda..b66c4740a8 100644 --- a/content/posts/fas-verification-automation.md +++ b/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! diff --git a/content/posts/fedora-eln.md b/content/posts/fedora-eln.md index b52ad02900..9cd40df385 100644 --- a/content/posts/fedora-eln.md +++ b/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: diff --git a/content/posts/weekly/May-2022.md b/content/posts/weekly/May-2022.md index c02d5cb159..91a4f40ebf 100644 --- a/content/posts/weekly/May-2022.md +++ b/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)