Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.packit.yaml is too verbose, and keeps folks from onboarding #574

Open
stefwalter opened this issue Oct 18, 2019 · 1 comment
Open

.packit.yaml is too verbose, and keeps folks from onboarding #574

stefwalter opened this issue Oct 18, 2019 · 1 comment

Comments

@stefwalter
Copy link

@stefwalter stefwalter commented Oct 18, 2019

Hi yall. Kudos on getting Packit Service running and stable and tested. Nice stuff!

I'm looking at a specific yaml from osbuild, and would like to give the feedback about the usability of the project. I believe that the lack of usability will turn away contributors. They have to understand about a lot of Fedora services, and unnecessary stuff in order to write a basic Packit file.

https://github.com/osbuild/osbuild/blob/21d91fd6df619d29fad0a06730881c49eb06082f/.packit.yaml#L1

Because osbuild has all of these lines, my assumption is that they were forced to include them. Success looks like a packit.yaml for osbuild that is 5 or 6 lines long. I'd like to keep rather than turn away users of Packit.

# we have the specfile in the root of our repository
specfile_path: osbuild.spec
  1. This should be a default path. If the spec file has the default name as prescribed by RPM, and is in the root of the project, there should be zero requirement to have specfile_path line.
# when doing an update in Fedora, we want to copy the spec file and the config file
synced_files:
  - osbuild.spec
  - .packit.yaml
  1. This should be default. There should be no reason for the project to include a synced_files section to just copy over the default files that Packit already knows are necessary for a project to work in dist-git. It is Packit's responsibility to make sure that a project works in dist-git, having the maintainer step in should be a extraordinary non-default step.
upstream_project_name: osbuild
downstream_package_name: osbuild
  1. These should be defaults. There should be no need to include these lines if the GitHub project has the same name as the Fedora project.
jobs:
  # trigger a COPR build for push events in open PRs
  - job: copr_build
    trigger: pull_request
    metadata:
      targets:
      - fedora-30-x86_64
      - fedora-31-x86_64
      - fedora-rawhide-x86_64
  # this is triggered by a commit on src.fedoraproject.org, not Github!
  # e.g. in case of mass rebuild or automated changes of spec file (e.g. Python packagers)
  # it will create a PR on Github with changes in synchronized files
  1. The jobs necessary to run a Packit build against Fedora rawhide should be default part of Packit.

  2. It should not be necessary to know about or see "COPR" in order to get your project to build on other targets.

  - job: sync_from_downstream
    trigger: commit
  # create a PR on src.fedoraproject.org containing updated spec file and new sources (tarball)
  # triggered by Github release
  1. Turning on basic syncing with Fedora should be one or two lines maximum. This should be a default job included once syncing is turned on.
  - job: propose_downstream
    trigger: release
    metadata:
      dist-git-branch: master
  # The same as above only for f31
  1. Again syncing with Fedora should be one or two lines maximum. By default we should be syncing against all the targets requested during build above. But only if packit has access to update them.
  - job: propose_downstream
    trigger: release
    metadata:
      dist-git-branch: f31
  - job: propose_downstream
    trigger: release
    metadata:
      dist-git-branch: f30
@stefwalter stefwalter changed the title .packit.yaml verbosity prevents onboarding of components .packit.yaml is too verbose, and keeps folks from onboarding Oct 18, 2019
@lachmanfrantisek

This comment has been minimized.

Copy link
Contributor

@lachmanfrantisek lachmanfrantisek commented Oct 21, 2019

@stefwalter Thanks for the proposal! Some of the points are already covered by existing issues.

Since all of these can be done in parallel, we can create an issue for each of them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.