diff --git a/content/_index.md b/content/_index.md index 243001940..894588643 100644 --- a/content/_index.md +++ b/content/_index.md @@ -81,6 +81,6 @@ and create [Bodhi](https://bodhi.fedoraproject.org) updates! [Learn more.](/docs [install locally](/docs/guide/#have-packit-tooling-installed-locally) and start using right away, -2. a [service]({{< ref "packit-service" >}}), which provides you feedback +2. a [service]({{< ref "guide" >}}), which provides you feedback on how is your project integrated with [Fedora Linux](https://getfedora.org), [CentOS Stream](https://www.centos.org/centos-stream/) and other distributions. diff --git a/content/docs/CLI/_index.md b/content/docs/CLI/_index.md index 9470b0abd..15a91dd51 100644 --- a/content/docs/CLI/_index.md +++ b/content/docs/CLI/_index.md @@ -8,8 +8,70 @@ bookCollapseSection: true # Packit CLI -To install [packit CLI](https://github.com/packit/packit) -follow [our guide](/docs/guide/#have-packit-tooling-installed-locally). +## Installation + +There are various ways how to install [packit CLI](https://github.com/packit/packit). +Pick what suits you the best: + +### Fedora Linux + + $ sudo dnf install packit + +### Red Hat Enterprise Linux or CentOS Stream 8 + +On RHEL/CentOS 8 you can install RPM from [EPEL](https://fedoraproject.org/wiki/EPEL) repository. +On CentOS, some dependencies are in PowerTools repository, so you have to enable it: + + $ sudo dnf install dnf-plugins-core epel-release + $ sudo dnf config-manager --set-enabled powertools + $ sudo dnf install packit + +### Via Fedora COPR + +You can also help us test the latest development snapshot by installing packit +built from the main branch in Copr: + + $ sudo dnf copr enable packit/packit-dev + $ sudo dnf install packit + $ # OR in case you have packit already installed from the Fedora repositories: + $ sudo dnf upgrade packit + +### From PyPI + +We publish packit to PyPI and it's available as `packitos` project — **packit +at PyPI is something different**. + + $ pip install --user packitos + +### From Source + +... or installing it directly from GitHub: + + $ pip install --user git+https://github.com/packit/packit + +### In a container + +If none of the above work for you, try running it in a container +from our Fedora based image. It contains packit installed from `main` branch, +i.e. the same you'd get by pip installing from Github. + + $ podman run -ti --rm -v $PWD:/src:z quay.io/packit/packit bash + $ packit + Usage: packit [OPTIONS] COMMAND [ARGS]... + +Depending on the command you want to perform you need to mount secrets and +configuration files, like in the following examples: + +#### Copr build + + $ podman run -ti --rm -v ~/.config/copr:/root/.config/copr:z -v $PWD:/src:z quay.io/packit/packit bash + $ packit build in-copr + +#### Koji build + + $ podman run -ti --rm -v ~/.ssh/:/root/.ssh:z -v $PWD:/src:z quay.io/packit/packit bash + $ fkinit -u + $ packit build in-koji ## Commands diff --git a/content/docs/_index.md b/content/docs/_index.md index 3fbb32000..9ff8b647d 100644 --- a/content/docs/_index.md +++ b/content/docs/_index.md @@ -8,7 +8,6 @@ bookCollapseSection: true * [About]({{< ref "about" >}}) - Key principles of Packit. * [Onboarding Guide]({{< ref "guide" >}}) - How to start using Packit. -* [Packit Service]({{< ref "packit-service" >}}) - GitHub App that helps you continuously ensure that your project work in Fedora OS. * [Testing Farm]({{< ref "testing-farm" >}}) - Guide to Packit's service for running tests. * [Frequently Asked Questions]({{< ref "faq" >}}) - Whys, Whats, contacts. * [Source-git](/docs/source-git/) - Source-git concept and how to work with it. diff --git a/content/docs/configuration.md b/content/docs/configuration.md index 667e87ed3..4ab597aba 100644 --- a/content/docs/configuration.md +++ b/content/docs/configuration.md @@ -11,10 +11,8 @@ You should place the file in the root of your upstream repo. Packit accepts thes * `.packit.yaml` * `.packit.yml` -* `.packit.json` * `packit.yaml` * `packit.yml` -* `packit.json` Both Packit Service and packit tool use this configuration file. @@ -816,14 +814,3 @@ them in a public (such as a GitHub repository). The configuration file here is located on your workstation, please do NOT confuse it with a config file for your project - that one is described above in the first section of this document. - -#### Server-side configuration - -These values are used to configure packit service. No need to bother with them, they serve as a documentation for us, packit service developers. - - Key name | Type | Description -------------------------------|-----------------|---------------------------------------------------------------------- - `keytab_path` | string | path to a Kerberos keytab file (requires `fas_user` to be set) - `github_app_id` | string | github app ID used for authentication - `github_app_cert_path` | string | path to a certificate associated with a github app - `webhook_secret` | string | when specified in a Github App settings, GitHub uses it to create a hash signature with each payload diff --git a/content/docs/guide.md b/content/docs/guide.md index 4f585036a..bc253bfd8 100644 --- a/content/docs/guide.md +++ b/content/docs/guide.md @@ -1,152 +1,321 @@ --- -title: Onboarding Guide +title: Packit Onboarding Guide weight: 2 +aliases: [/packit-service, /packit-as-a-service, /docs/packit-as-a-service] --- -# Onboarding Guide +# Packit Onboarding Guide -## Agenda +Let's take a look on how to start using Packit and how to get the most out of it. -We have split the on-boarding process into multiple stages: +This guide is focused on the service use-case, but Packit is also available as a [CLI tool](https://github.com/packit/packit/blob/main/README.md), +so you can always [try things locally](/docs/cli/) on your own. +Note that running tests in Testing farm infrastructure is not currently supported with the CLI tool. +Unlike the service, CLI uses your own identities when connecting to other service like [Copr](https://copr.fedorainfracloud.org/) +or [Fedora dist-git](https://src.fedoraproject.org/). +Packit CLI is **NOT** a client of the Packit GitHub app, +`packit` command directly interacts with the services. -1. Have packit tooling installed locally. -2. RPM builds pass on your laptop. -3. You are approved to use Packit Service. -4. The project has successful builds inside the service. -5. Packit service handles Fedora Rawhide updates for you. +To start using Packit, you need to do three things: -We welcome all kinds of suggestions to this guide, feel free to [open a new issue -here](https://github.com/packit/packit.dev/issues/new). +1. set up integration (so Packit is notified about your activities and can provide feedback) +2. be approved (self-done mapping of your forge identity to FAS identity so we know who you are) +3. configure the wanted features -## Have packit tooling installed locally -In order to start using packit, we suggest you install the tooling locally. All -the logic is baked inside the `packit` command - so once `packit srpm` (the command -to create a source RPM locally from the current snapshot of the project) starts -passing for you, it should work inside packit service as well. +## 1. Set up Packit integration + +The integration is dependent on the service the upstream project is hosted on. +In case you want to use Packit on your downstream repository for downstream jobs +([Koji build](/docs/configuration/#koji_build) and [Bodhi update](/docs/configuration/#bodhi_update)), +you don't need to enable anything. +Just place your config file into the dist-git repository. + +Here are the supported git-forges: + +### GitHub + +The majority of Packit users host their projects on GitHub, therefore we focus mainly on supporting the GitHub App. +All of our workflows are supported and tested on GitHub. +We utilize majority of new GitHub features that can be used in GitHub Apps. + + +### How to set up Packit on GitHub + +1. Navigate to the ["Packit-as-a-Service" GitHub + application](https://github.com/marketplace/packit-as-a-service). + ![Packit GitHub application](/images/guide/guide_github_app.png) +2. Under "Pricing and setup", click "Install it for free". + ![Packit GitHub application: Plan](/images/guide/guide_github_app_plan.png) +3. Click "Complete order and begin installation". + ![Packit GitHub application: Order](/images/guide/guide_github_app_order.png) +4. Install the "Packit-as-a-Service" to repositories of your choice. + ![Packit GitHub application: Installation](/images/guide/guide_github_app_installation.png) -### Fedora Linux +Once installed, you will see the ["Packit-as-a-Service" GitHub +application](https://github.com/marketplace/packit-as-a-service) in your +project settings. In the left sidebar, click "Integration & services" and you +will see the application displayed there. - $ sudo dnf install packit -### Red Hat Enterprise Linux or CentOS Stream 8 +### Staging instance -On RHEL/CentOS 8 you can install RPM from [EPEL](https://fedoraproject.org/wiki/EPEL) repository. -On CentOS, some dependencies are in PowerTools repository, so you have to enable it: +[Packit-as-a-Service-stg](https://github.com/apps/packit-as-a-service-stg) GitHub App +runs the latest code. It can be used to verify latest changes until they get +(every Tuesday) into the [production instance](https://github.com/marketplace/packit-as-a-service). +If you want to enjoy the freshest features and help us with the development, +see more details [here](https://github.com/packit/packit/discussions/1530). - $ sudo dnf install dnf-plugins-core epel-release - $ sudo dnf config-manager --set-enabled powertools - $ sudo dnf install packit +![Packit GitHub application: Staging instance](/images/guide/guide_github_app_stg.png) -### Via Fedora COPR -You can also help us test the latest development snapshot by installing packit -built from the main branch in Copr: +### GitLab + +GitLab support is mainly experimental and is influenced by the presence of CentOS Stream source-git workflow. +**We do not verify** the functionality of the GitLab support on a day-to-day basis as we do with the GitHub App. + + +#### How to set up Packit on GitLab + +GitLab doesn't have an app functionality and we don't use the [Integrations](https://docs.gitlab.com/ee/user/project/integrations/overview.html) as it doesn't solve authentication. +To enable Packit, you need to manually configure a webhook. + +1. Go to `Settings → Webhooks` and add https://prod.packit.dev/api/webhooks/gitlab or https://stg.packit.dev/api/webhooks/gitlab as the `URL`. + ![GitLab webhooks](/images/gitlab/webhooks.png) +2. Select `Push events`, `Comments`, `Issues events`, `Merge request events` and `Release events` as the `Triggers`. + Do not provide `Secret token` yet and click `Add webhook`. + You should see the created hook at the bottom of the page now. + ![Setting up webhook](/images/gitlab/set_up_webhook.png) +3. Select `Test` and for example `Merge requests events`. + At the top of the page appears a red `Hook executed successfully but returned HTTP 401 "X-Gitlab-Token not in request.headers"`. +4. Wait a bit and check `Issues` of the project and after a while there should be + a new confidential `Packit-Service Authentication` issue with the instructions how to finish the setup. + +##### GitLab Pipelines + +With some limitations (but tweakability) you can also use Packit as a GitLab pipeline +using the Packit's [CLI](/docs/cli) from the regularly built +[`quay.io/packit/packit` image](https://quay.io/repository/packit/packit). +As you can see in the following example, it's really straightforward and explicit: + +```yaml +image: quay.io/packit/packit + +srpm_build: + stage: build + script: + - packit srpm + artifacts: + paths: + - "*.src.rpm" + expire_in: 1 week +``` + +### Pagure - $ sudo dnf copr enable packit/packit-dev - $ sudo dnf install packit - $ # OR in case you have packit already installed from the Fedora repositories: - $ sudo dnf upgrade packit +We have rudimentary support for the Pagure instances since they are used in the downstream workflow. +Packit cannot be set up as a CI (in the same sense as on GitHub or GitLab) on Pagure instances, +since the demand for this feature is not significant. +The differences between GitHub/GitLab and Pagure APIs would result in many workarounds having to be implemented, if it would be possible at all. +You can track the progress in the [related issue](https://github.com/packit/packit-service/issues/556) on GitHub. -### From PyPI -We publish packit to PyPI and it's available as `packitos` project — **packit -at PyPI is something different**. +## 2. Approval - $ pip install --user packitos +As a next step, you need to have a valid [Fedora Account System](https://fedoraproject.org/wiki/Account_System) +account to be able to start using Packit Service in an upstream project. +For GitHub, we have an automated way of self-approval, +for other instances, [contact us](/#contact) and we will approve you manually. +We require our new users to have `GitHub Username` field set in the FAS account so that we can automatically +check for the match between the `GitHub Username` field in the FAS account and the GitHub account that triggers the verification. +(If you don't know, where to set this value, +the URL looks like this: `https://accounts.fedoraproject.org/user//settings/profile/#github`.) -### From Source +During the installation, we try to check the FAS account with the same +username as the GitHub account that triggers the installation and if the check +fails, we create a new issue in our +[allowlist tracker](https://github.com/packit/notifications/issues/). +(You will be tagged in that issue and should get a GitHub notification about that.) -... or installing it directly from GitHub: +![Packit approval issue](/images/guide/guide_approval_issue.png) - $ pip install --user git+https://github.com/packit/packit +You can provide the FAS account in a comment +as `/packit verify-fas ` in the issue we create +for your installation. This will trigger the automatic check. +Until that, you will get a neutral status with `Namespace is not allowed!` +message on your commits. -### In a container +![Packit approval issue: add mapping in the FAS settings](/images/guide/guide_approval_fas_settings.png) +![Packit approval issue: add mapping by a comment](/images/guide/guide_approval_comments.png) -If none of the above work for you, try running it in a container -from our Fedora based image. It contains packit installed from `main` branch, -i.e. the same you'd get by pip installing from Github. +Besides that: +* If you want to configure builds via Packit, + your software needs to comply with [Copr guidelines](https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr) + since we use [Fedora Copr](src.fedoraproject.org/) for the builds. + Therefore, please, make sure you read them before configuring the [Packit build job](/docs/configuration/#copr_build). +* If you are interested in using [internal instance of the Testing Farm](https://docs.testing-farm.io/general/0.1/services.html#_red_hat_ranch) + to run your tests in, please, [reach out to us](/#contact), since for this job, an additional approval on our side is needed. +* For retrying the [build](/docs/configuration/#copr_build) and [test](/docs/configuration/#tests) jobs via `/packit build` and `/packit test` pull request comments, + you need to have write access to the repository or be the author of the pull request. +* Similarly, for retrying the [propose downstream job](/docs/configuration/#propose_downstream) via `/packit propose-downstream` issue comment, + you need to have write access to the repository. - $ podman run -ti --rm -v $PWD:/src:z quay.io/packit/packit bash - $ packit - Usage: packit [OPTIONS] COMMAND [ARGS]... -Depending on the command you want to perform you need to mount secrets and -configuration files, like in the following examples: +## 3. Configuration -#### Copr build +Packit uses a configuration file to let Packit know what to do, when to do it and how. +As a format, it uses YAML and here are all the valid names: +* `.packit.yaml` +* `.packit.yml` +* `packit.yaml` +* `packit.yml` - $ podman run -ti --rm -v ~/.config/copr:/root/.config/copr:z -v $PWD:/src:z quay.io/packit/packit bash - $ packit build in-copr +And where do you need to place this config file? +Whenever you need to use Packit -- the concept is easy: +Packit loads the config file from the repository and commit related to the event it reacts to. +E.g. if Packit reacts to a pull request, it takes config from the HEAD commit of the pull request, +if Packit works with releases, the release commit is used +and if Packit works with downstream Koji build, +the respective dist-git commit is used. -#### Koji build +You know how to call this file, where to put it, but what should you fill inside? - $ podman run -ti --rm -v ~/.ssh/:/root/.ssh:z -v $PWD:/src:z quay.io/packit/packit bash - $ fkinit -u - $ packit build in-koji +In the following parts, we will cover some basic concepts used in the Packit config file. +More details can be found on a dedicated [configuration page](/docs/configuration/). -## RPM builds pass on your laptop. +### Basic configuration -Once you install packit locally, it's time to fill `.packit.yaml` — the -configuration file packit is using. Packit can help to fill the initial -template by running the `init` command: +You need to provide some basic information to let Packit understand your project and package. +You can use `packit init` command (when [running Packit locally](/docs/cli/)) to get a basic structure. +It will look like this (name of the package is guessed from the directory name): - $ packit init - $ cat .packit.yaml ```yaml # See the documentation for more information: # https://packit.dev/docs/configuration/ -specfile_path: packit.dev.spec +specfile_path: package.spec # add or remove files that should be synced files_to_sync: - - packit.dev.spec + - package.spec - .packit.yaml # name in upstream package repository/registry (e.g. in PyPI) -upstream_package_name: packit.dev +upstream_package_name: package # downstream (Fedora) RPM package name -downstream_package_name: packit.dev +downstream_package_name: package ``` -Head on to page [configuration]({{< ref "configuration" >}}) to learn more -about the config file. +We know that every project is a bit different and Packit can't guess everything +so you can (re)define various other options. +The full list can be found [here](/docs/configuration/#top-level-keys). -Packit supports actions and hooks: you can define your own commands which would -replace packit's implementation (e.g. get version, or create a tarball) or run -specific commands after the upstream repo is cloned. Please read more about -actions here: [actions]({{< ref "actions" >}}). +#### Version handling + +There are a few version-related config options you might need to set: +* [`upstream_tag_template`](/docs/configuration/#upstream_tag_template): + Specifies a format of upstream tags if it doesn't contain just a version. +* [`get-current-version` action](/docs/actions/): + Command to get a project version in the current state of the project. +* [`release_suffix`](/docs/configuration/#release_suffix): + Used to influence release field of artifacts provided by Packit. + + +### Jobs + +Packit's feature set is really wide and does not need to to be used as a whole pipeline. +To let user decide what and when should run, Packit uses concept of so-called `jobs`. +Each job represents a feature of Packit. All the jobs are defined under the `jobs` key. +For each job you need to specify the following information: +* `job`: the type of the job, the feature you want Packit to do. +* `trigger`: when the job is run (`pull_request`, `commit` or `release`). +* additional information needed for the job (like what targets to build, for what branch to run the job,...) + +(Note that for each job, not all the triggers are supported.) + +As an example you can take a look at the following config snippet +(these are also the default jobs used if you don't set the `jobs` key): +```yaml +jobs: +- job: copr_build + trigger: pull_request + targets: [fedora-stable] + +- job: tests + trigger: pull_request + targets: [fedora-stable] + +- job: propose_downstream + trigger: release + dist_git_branches: + - fedora-all +``` + +Most of the attributes can be defined both on global level (outside of the `jobs` key) +or for a single job only (like e.g. `targets` in the snippet above). +More about this overriding mechanism can be found [here](/docs/configuration/#overriding-global-parameters). +Another useful feature are [aliases](/docs/configuration/#aliases) used to avoid +hardcoded values that changes when there is a new distribution release. + + +### Available jobs + +* [`copr_build`](/docs/configuration/#copr_build): An RPM build triggered for pull-requests, new branch commits or releases. + (Can be used to verify that package is buildable, + to easily install package including the proposed change + 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. +* [`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. +* [`bodhi_update`](/docs/configuration/#bodhi_update): A Bodhi update created for a successfully finished Koji build. -Packit needs an RPM spec file to build your package. The spec file does not -need to be included in the upstream repo and can be generated on the fly or -downloaded (e.g. from Fedora dist-git). Please check out our [FAQ]({{< ref -"faq" >}}) to read about some other common questions. -You can also read more about the SRPM process in [the document]({{< ref -"cli/srpm" >}}) dedicated to the `srpm` command. +More about the jobs and how to tweak them can be found on a [configuration page](/docs/configuration#jobs). -Is your `packit srpm` finally passing? If not, feel free to reach out to us. If -yes, let's proceed to the next level. +### Actions -## Running from the dist-git repository +Actions are a way how to redefine or tweak the Packit's workflows. +These are user-defined commands that can replace a part of Packit's job (e.g. to get version, or to create a tarball) +or are run in a particular step as a hook (with no action run by default). + +Take a look at the tables [here](/docs/actions/) to know what actions are available for each job. + + +### How to try that for real + +In order to start using Packit, we suggest you [install the tooling locally](/docs/cli/#installation). All +the logic is baked inside the `packit` command - so once `packit srpm` (the command +to create a source RPM locally from the current snapshot of the project) starts +passing for you, it should work inside packit service as well. + + +#### RPM builds pass on your laptop + +Packit needs an RPM spec file to build your package. The spec file does not +need to be included in the upstream repo and can be generated on the fly or +downloaded (e.g. from Fedora dist-git). +Please check out our [FAQ]({{< ref "faq" >}}) to read about some other common questions. + +You can also read more about the SRPM process +in [the document]({{< ref "cli/srpm" >}}) dedicated to the `srpm` command. + +##### Running from the dist-git repository When you are not allowed or do not want to run packit command from the upstream git repository, you can run commands from the cloned dist-git repository in the same way as you do from upstream. Make sure, that you specify the `upstream_project_url` in your configuration. -## You are approved to use Packit Service. +Is your `packit srpm` finally passing? If not, feel free to reach out to us. +If yes, let's proceed to the next level. -In order to start using packit service, our GitHub app, you need to [install it -in your GitHub projects]({{< ref "packit-service" >}}) and get approved. -(The approval process can be done by you without any manual interaction -by the Packit team.) - -## The project has successful builds inside the service. +#### The project has successful builds inside the service If a SRPM can be created locally, all should be good in the service as well. That's the theory. In practice, your laptop and packit service sandbox @@ -163,9 +332,9 @@ In any case, feel free to reach out to us if you are having troubles and we'd be glad to help. -Packit supports various functions in form of jobs you can configure. -(All the jobs are described [here](https://packit.dev/docs/configuration/#supported-jobs).) -In order to get RPM builds for every change in your project, you need add a +As described [above](#jobs), Packit supports various functions in form of jobs you can configure. +Let's try the most favourite one: Copr build. +In order to get RPM builds for every change in your project, you need to add a section `jobs` inside your .packit.yaml and set up a `copr_build` job to do RPM builds for every change in a PR: @@ -185,13 +354,67 @@ 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 updates for you. +## Check that Packit works -So you already have a `jobs` section in your config. Let's extend it with another -jobs that will handle the Fedora updates: `propose_downstream`, `koji_build` and `bodhi_udpate`. -These are explained in detail in our [release guide](fedora-releases-guide.md). +With the configuration above, Packit is able only to build your changes and provide them as RPMs. +Once you create a pull request, Packit builds the code from the +pull request in Copr repository and reports back Copr build status to the pull request. + +An example of Packit pull request: + +![Packit pull request](/packit-service-pr.png) + +## How to re-trigger Packit actions in your pull request? + +In general, you can put a `/packit ` comment +to trigger the Packit job manually. +So for [Copr builds](/docs/configuration/#copr_build), Packit is able to trigger new builds based on a pull request comment: + /packit copr-build + +or the shorter version + + /packit build + +So whenever you run into a flake or feel like you want to retrigger, just type +that comment into the PR and enjoy some fine, fresh builds. + +For [`propose_downstream`](/docs/configuration/#propose_downstream), you need to place that comment to any issue. + +The requirements stated [above](#approval) apply, so if you see this message + + Only users with write or admin permissions to the repository can trigger + Packit-as-a-Service + +it means the author of the pull request does not have write access to the +repository so the build cannot be scheduled. This is a perfect case for +maintainers of the repository to post `/packit build` in the PR to get a build. + +In Github Checks interface, it is also possible to re-trigger a specific task just by clicking on `Re-run` +for the particular check: + +![Re-run Github check](/github-check-rerun.png) + +Or it is possible to re-trigger every failed task using a pull request comment + + /packit rebuild-failed + +which builds only failed builds and similar for testing farm + + /packit retest-failed + +to re-trigger every failed test. + +#### Packit handles Fedora updates for you. + +So you already have a `jobs` section in your config. Let's extend it with another +jobs that will handle the Fedora updates: `propose_downstream`, `koji_build` and `bodhi_udpate`. +These are explained in detail in our [release guide](/docs/fedora-releases-guide). 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](https://packit.dev/#contact). + + +We welcome all kinds of suggestions to this guide, feel free to [open a new issue +here](https://github.com/packit/packit.dev/issues/new). \ No newline at end of file diff --git a/static/images/guide/guide_approval_comments.png b/static/images/guide/guide_approval_comments.png new file mode 100644 index 000000000..2e54dd1a6 Binary files /dev/null and b/static/images/guide/guide_approval_comments.png differ diff --git a/static/images/guide/guide_approval_fas_settings.png b/static/images/guide/guide_approval_fas_settings.png new file mode 100644 index 000000000..95e788532 Binary files /dev/null and b/static/images/guide/guide_approval_fas_settings.png differ diff --git a/static/images/guide/guide_approval_issue.png b/static/images/guide/guide_approval_issue.png new file mode 100644 index 000000000..77d60c6b3 Binary files /dev/null and b/static/images/guide/guide_approval_issue.png differ diff --git a/static/images/guide/guide_github_app.png b/static/images/guide/guide_github_app.png new file mode 100644 index 000000000..9f19d1f50 Binary files /dev/null and b/static/images/guide/guide_github_app.png differ diff --git a/static/images/guide/guide_github_app_installation.png b/static/images/guide/guide_github_app_installation.png new file mode 100644 index 000000000..1d5e6a7b1 Binary files /dev/null and b/static/images/guide/guide_github_app_installation.png differ diff --git a/static/images/guide/guide_github_app_order.png b/static/images/guide/guide_github_app_order.png new file mode 100644 index 000000000..af98ff76d Binary files /dev/null and b/static/images/guide/guide_github_app_order.png differ diff --git a/static/images/guide/guide_github_app_plan.png b/static/images/guide/guide_github_app_plan.png new file mode 100644 index 000000000..8a1293e47 Binary files /dev/null and b/static/images/guide/guide_github_app_plan.png differ diff --git a/static/images/guide/guide_github_app_stg.png b/static/images/guide/guide_github_app_stg.png new file mode 100644 index 000000000..08e29fee8 Binary files /dev/null and b/static/images/guide/guide_github_app_stg.png differ