Fix Up RHEL Builds

[Mab879]

This PR splits the build into a RHEL path and Fedora path. Fedora path keeps using go-vendor-tools. RHEL manually creates the go-vendor-tools archive.

[packit-as-a-service]

Failed to load packit config file:

Cannot parse package config. ValidationError({'jobs': {2: {'job': ['Must be one of: propose_downstream, pull_from_upstream, sync_from_downstream, copr_build, upstream_koji_build, koji_build, tests, bodhi_update, vm_image_build, koji_build_tag.']}, 3: {'job': ['Must be one of: propose_downstream, pull_from_upstream, sync_from_downstream, copr_build, upstream_koji_build, koji_build, tests, bodhi_update, vm_image_build, koji_build_tag.']}}})

For more info, please check out the documentation or contact the Packit team. You can also use our CLI command config validate or our pre-commit hooks for validation of the configuration.

[Mab879]

/packit rebuild-failed

[vojtapolasek]

@Mab879 looks good. But I have one hing I would like to know your opinion on.
I don't like the fact that job definition are duplicated for commit and PR case.
I consulted Claude and this is the result.
I did not know about yaml anchors. What do you think, does it make sense?

PR #129 splits the build into a fedora path and a rhel path, and each path
needs its own job for both the pull_request and commit triggers (Packit's
trigger field only accepts a single value per job — you can't list
[pull_request, commit] on one job block). That's why .packit.yaml now has
4 job entries instead of 2.

The 4 entries are still necessary, but the duplication between the
pull_request and commit variant of each platform can be removed using
plain YAML anchors/merge keys, so each platform's config (deps, actions,
targets) is written once and the trigger-specific bits are the only thing
that differs visually.

How YAML anchors work

YAML anchors are a core YAML feature, not something Packit-specific:

• &name — anchor: tags a node (mapping, list, or scalar) with a label.
• *name — alias: copies that node's content verbatim wherever it's used.
• <<: *name — merge key: for mappings specifically, inlines the
  anchored mapping's key/value pairs into the current mapping. Any key you
  also define alongside << overrides the value that came from the anchor.

Example:

- &fedora
  job: copr_build
  trigger: pull_request
  targets: [fedora-latest-x86_64]

- <<: *fedora
  trigger: commit
  branch: main

The second item resolves to:

job: copr_build
trigger: commit
targets: [fedora-latest-x86_64]
branch: main

The merge (<<) is applied first, then sibling keys written literally win
over the merged-in value for the same key. Note this only replaces matching
top-level keys wholesale — it doesn't deep-merge nested lists/maps, so e.g.
overriding targets means providing the whole new list, not appending to it.

This is standard YAML 1.1 merge-key syntax, supported by PyYAML, Ruby's
Psych, yq, GitHub Actions, etc. — and Packit's own docs use this exact
pattern to reduce job duplication. It only reduces textual duplication in
the source file; Packit still expands and sees 4 fully independent job
entries at runtime, so behavior is unchanged.

Suggested .packit.yaml

upstream_package_name: cvetool
downstream_package_name: cvetool
specfile_path: cvetool.spec
upstream_tag_template: v{version}

jobs:
  - &fedora
    job: copr_build
    identifier: fedora
    trigger: pull_request
    enable_net: True
    targets:
      - fedora-latest-x86_64
    srpm_build_deps:
      - golang
      - go-vendor-tools
    actions:
      fix-spec-file:
        - go_vendor_archive create cvetool.spec

  - <<: *fedora
    trigger: commit
    branch: main
    preserve_project: True
    targets:
      - fedora-stable-x86_64

  - &rhel
    job: copr_build
    identifier: rhel
    trigger: pull_request
    enable_net: True
    targets:
      - rhel-10-x86_64
      - rhel-9-x86_64
      - epel-10-x86_64
      - epel-9-x86_64
    srpm_build_deps:
      - golang
    actions:
      fix-spec-file:
        - go mod tidy
        - go mod vendor
        # We wrap the tar command in bash -c so $PACKIT_PROJECT_VERSION is evaluated
        - bash -c "tar -cjvf cvetool-${PACKIT_PROJECT_VERSION}-vendor.tar.bz2 vendor/"

  - <<: *rhel
    trigger: commit
    branch: main
    preserve_project: True

[Mab879]

YAML anchors usually seem a bit too clever to me. But I I'm willing to try them out there.

Fun fact, when I did my own review of this PR Claude called YAML anchors "not well supported" in Packit.

[vojtapolasek]

LGTM, thank you.