[Part 2] My GSOC 2020 journey with Packit (Fedora)

Hello everyone!

It’s Shreyas again. Today, I will be sharing my current work and status of packit-service on Gitlab.

Integrating Packit-as-a-Service into your project on any Gitlab Instance

Just like Github integration its pretty straightforward add one config file to your repository together with the RPM spec file and you’re good to go.

Adding webhook to the repository

In order to send events data to packit-service we need to setup webhook for the project by going into settings -> webhooks

Inside the webhook settings you need to add URL and the secret token, Got from packit-service (Still working on it) with minimum trigger permissions of Push events, Comments, Issue events, Merge request events.

That’s it on the settings part!

Now,

Here we will be looking into the testing repository of packit-service on Gitlab packit-service/hello-world. Here is an example of the basic .packit.yaml and .spec file you need to add to define configuration of packit-service.

1. .packit.yaml

---
specfile_path: hello.spec
synced_files:
  - hello.spec
# actions:
#   post-upstream-clone: "python3 setup.py sdist --dist-dir ."
# current_version_command: ["python3", "setup.py", "--version"]
# create_tarball_command: ["python3", "setup.py", "sdist", "--dist-dir", "."]
jobs:
- job: copr_build
  trigger: pull_request
  metadata:
    targets:
    - fedora-30-x86_64
    - fedora-31-x86_64
    - fedora-rawhide-x86_64

- job: copr_build
  trigger: release
  metadata:
    targets:
    - fedora-stable

- job: tests
  trigger: pull_request
  metadata:
    targets:
    - fedora-30-x86_64
    - fedora-31-x86_64
    - fedora-rawhide-x86_64

- job: propose_downstream
  trigger: release
  metadata:
    dist-git-branch: fedora-all

2) Example for the spec file from packit-service/hello-world

Name:           hello
Version:        0.1.0
Release:        1%{?dist}
Summary:        Nice and a polite tool to make your day
License:        MIT
URL:            https://gitlab.com/packit-service/hello-world
Source0:        hello-%{version}.tar.gz
BuildArch:      noarch
BuildRequires:  python3-devel

%description
%{summary}


%prep
%autosetup -n %{name}-%{version}

%build
%py3_build

%install
%py3_install

%files
%license LICENSE
%{_bindir}/hello
%{python3_sitelib}/*
%doc README.md

%changelog
* Thu May 02 2019 Tomas Tomecek <ttomecek@redhat.com> - 0.1.0-1
- initial upstream release: 0.1.0

You can find detailed information of the configs here.

How to check Packit Service is correctly configured and works?

Now, when you create a Merge Request, Packit Service builds the code from the merge request in COPR repository and reports back COPR build status to the latest commit of the merge request.

Here is an example from packit-service/hello-world.

Here if the packit-service-user does not have access to the repository from which the merge request is coming. Packit-service will report the build status as a comment in the merge request (Additionally will ask you for the project access).

Example, without the project access.

What’s next and problems faced?

Now, the next thing to work on is the webhook authentication. As unlike Github, we(packit-service) will need to handle all the webhook authentication and is not automated in the Gitlab part.

• So, next step will be to work on the authentication and on-board a project from a gitlab-instance.
• Currenly, Gitlab does not support multi-stage build with external pipelines and all builds are shown in single external stage. Here, Gitlab will probably soon support it and I am keeping the track of the gitlab issue #19177. When the support for this is added, I will be working on support multi-stage external pipelines.

Hope this was a good read, drop by in the comments if you have something to say!

That’s it for now!