![\"Tatranska](\"/assets/images/tatranska-lomnica-dhodovsk-4b1ceac1afbd0df47187f6571a3d4db9.jpg\")
Copyright (c) Dominika Hodovska. This work is licensed under a Creative Commons Attribution 4.0 International License.rmdepcheck and license-validate tests on PRs. (packit-service#3089)/packit test command now supports testing with builds from multiple pull requests. You can specify multiple PRs using the format /packit test namespace/repo#123 namespace/repo#456 or GitHub URLs, allowing you to combine artifacts from several PRs in a single test run. (packit-service#3118)rebuild-failed,\nretest-failed or test with --identifier.\n(packit-service#3112)version_update_mask, users can now use a new version_update_specifiers configuration option to control the upstream versions allowed to be release-synced. The option accepts PEP440 version specifier sets, for example version_update_specifiers: >=1.0,~=1.0. (packit#2710)logdetective_enabled to False in the service configuration file. (packit-service#3100)pull-from-upstream jobs with different version/tag filters. In conjunction with the Monitoring all release monitoring option this allows you to consume multiple release streams and freely configure Fedora releases you want to target with each. (packit-service#3083)help command in PR and issue comments.\n(packit-service#2853)rawhide PRs\nof ELN packages without dedicated eln branch independently.\n(packit-service#3032)pull-from-upstream via dist-git PR comment.\n(packit-service#3058)src.fedoraproject.org/tests/* namespace. (packit-service#3022)bodhi_extra_params configuration option to customize creating Bodhi updates.\n(packit#2682)version_suffix configuration option is now supported in Packit. This option is meant for appending information to the Version field in RPM spec files. This is useful for post-release snapshots following RPM versioning conventions. The version_suffix behaves similarly to the already existing release_suffix and also supports expansion of environment variables. (packit#2664)main branch are now supported in Fedora CI. (packit-service#2968)dist-git-branch context pointing to the target branch of the PR. (packit-service#2935). On epel10.y dist-git PRs they now use the CentOS Stream 10 Testing Farm compose, same as epel10. (packit-service#2953)--package parameter, which can be used when retriggering jobs in monorepositories via comments. The parameter is intended to specify the package, for which to run specified jobs. (packit-service#2850)rawhide pull requests of onboarded ELN packages that don't have designated eln branch. (packit-service#2950)https://github.com/namespace/repo/pull/<pr_id>,\ne.g. /packit test https://github.com/namespace/repo/pull/<pr_id>)\n(packit-service#2923)logdetective.analysis topic) containing state of analysis of failed build logs. (packit-service#2900)packit init now automatically retrieves the latest version of the pre-commit hook to be added to the user's pre-commit configuration file. (packit#2651)pyforgejo import that was introduced with a new upstream release. (packit/ogr#949)PACKIT_COPR_BUILD_ID in the Testing Farm tests. (packit/packit-service#2857)mock when no RPMs are provided when running packit test in the CLI. (packit#2636)eln dist-git branch and the Fedora-eln Testing Farm compose in Packit as Fedora CI.\n(packit#2630)specfile_path from configuration (or its default value) as the environment variable PACKIT_SPECFILE_PATH for all Packit actions. (packit#2589)We have added a new run-condition action that can be used to conditionally\ndisable downstream jobs during the execution and aims to solve the following\nissue. (packit#2608, packit-service#2810)
We got a contribution for a typo in the error message when our Packit CLI\ntracebacks. Thanks a lot for the contribution, @mulkieran. (packit#2612)
We have fixed a bug in validation of the job trigger. (packit#2616)
We have added support for handling of minor EPEL releases for Copr builds. (packit#2619)
upstream_package_name to the upstream_tag_template option. (packit#2604)packit config validate -c /tmp/my-custom-packit-config.yml. (packit#2556)Installability check is now being run as part of CI on dist-git pull requests. For more information, please refer to our documentation. (packit-service#2782)
Support for Forgejo pull requests has been added. (ogr#925)
--resultdir argument in build_in_mock now defaults to the current directory (\".\"), preventing loss of build artifacts when not explicitly set. (packit#2567)tf_extra_params should now be included when submitting the automatic upstream installability check to the Testing Farm. (packit-service#2779)osh_options config option that allows you to customize OpenScanHub scans. (packit#2570)fast_forward_merge_into, version_update_mask is now correctly being taken into consideration. (packit#2551)config command group for configuration-related commands and moved the validate-config command under it, resulting in the new command being packit config validate. (packit#2559)/packit scratch-build. (packit-service#2770)propose_downstream/pull_from_upstream to fail if upstream git repo\ncontains submodules that are manipulated with in actions.\n(packit-service#2768)--base-nvr option when submitting scans to OpenScanHub.\nThe base NVR is pulled in from Koji to perform a differential scan.\n(packit#2569)use_target_repo_for_fmf_url configuration flag to bypass\nthe default passing of fork URLs for test requests.\n(packit-service#2752)actions that might modify them during release syncing.\nThis adds support for use cases like regenerating the spec file, see rust2rpm example.\n(packit#2521)This is also a breaking release that includes changes from the Packit 1.0.0, we\nhave opened PRs that should help you with migration if you are affected.
For more details please see the following blog post.
- in them. (contributed by Dan Čermák, specfile#445)We have added a --resultdir option for building in mock via our CLI\n(packit build in-mock).\n(packit#2475)
For our specfile users, there is a new\nconvenience method Sections.get_or_create() that allows you to manipulate\na section without checking if it exists first. If a section doesn't exist, it\nwill be appended to the end. For example, this will work properly even on\nspec files without %changelog:
with spec.sections() as sections:
changelog = sections.get_or_create(\"changelog\")
changelog[:] = [\"%autochangelog\"]
We have also switched our base images from CentOS 9 Stream to Fedora 41 to\nallow you using the features from the latest rpm 4.20.\n(deployment#622)
We have unified status names for VM Image builds.\n(packit-service#2679)
We have started building our container images\nfor alternative architectures.\n(packit-service#2675)
post-modifications, that is executed after all modifications to the spec file are done and in case of syncing release after all remote sources are downloaded and before uploading to lookaside cache. You can use it for example to construct an additional source that depends on the primary source (that may not yet be available in other actions). (packit#2474)/packit retest-failed which was retriggering also non failed tests. (packit-service#2665)fedora-distro-aliases library to expand Fedora aliases.\nThis is Packit's original code being improved and properly maintained by the Copr team.\nFor further suggestions about aliases, use github.com/rpm-software-management/fedora-distro-aliases.\n(packit#2470)_, which is ignored when parsing the file.\nThis is useful for storing YAML anchors in complex config files, e.g.:_:
base-test: &base-test
job: tests
fmf_path: .distro
jobs:
- <<: *base-test
trigger: pull_request
manual_trigger: true
- <<: *internal-test
trigger: commit
use_internal_tf: true
with_opts and without_opts in target-specific configuration of copr_build job to build with --with and --without rpmbuild options. (packit#2463)/osh-scans API endpoint. (packit-service#2614)fast_forward_merge_into syntax via --dist-git-branches-mapping in dist-git init. (packit#2456)We have added support for retriggering jobs that are configured for commit and release trigger. Retriggering can be done via commit comments on the relevant commit, using the usual comments, such as /packit build or /packit test, but the branch or tag need to be specified like this (without the arguments, we will default to commit trigger for the default branch of the repository):
/packit build --commit <branch-name>
or
/packit build --release <tag-name>
There is a new method for getting a single commit comment, supporting also retrieval and adding reactions in GitHub. (ogr#865)
We have improved the feedback for the Open Scan Hub job. You can now see if the scan is in a pending, running, canceled, failed, or successful state.\nA failed or canceled scan is shown as neutral and does not cause your pull request validation to fail. (packit-service#2543)
/packit test) now accepts --env option(s)\nto override environment variables passed to Testing Farm.\n(packit-service#2583)sync-release or bodhi_update jobs. (packit#2442)packit validate-config now checks for the existence of the downstream package. (packit#2436)--resolve-bug switch (comments accept comma-separated list of bugs, CLI accepts the switch multiple times (also -b)).\n(packit#2428 and packit-service#2560)packit init now adds working directories that are used in packit prepare-sources into the .gitignore file in the same directory where Packit config resides. (packit#2431)upstream_project_url presence in the configuration when pull_from_upstream job is configured was removed from validate-config, as this is no longer required. (packit#2423)pull_from_upstream job from dist-git pull requests. (packit-service#2542)bootstrap configuration option. (packit#2411)--csmock-args CLI option and csmock_args configuration. (packit#2402)dist_git_branches as in this example to utilise this functionality:{
\"rawhide\": {
\"fast_forward_merge_into\": [\"f40\"]
},
\"fedora-stable\": {}
}
pull-from-upstream is now supported also without specifying upstream_project_url in the configuration. For such cases, the upstream repository will not be detected and cloned during release syncing. (packit#2398)dist-git init command now allows upstream-git-url not to be specified. (packit#2387)/packit koji-tag comment command. (packit-service#2507)epel-10 is now correctly mapped to a centos-stream-10 when running tests. (packit-service#2508)PACKIT_TAG_NAME to the Testing Farm run when it's triggered by a release event.\nThanks @Frawless.\n(packit-service#2494)packit pull-from-upstream now allows omitting upstream_project_url in the configuration in which case the interaction with the upstream repository is skipped during release syncing. (packit#2354)sync_test_job_statuses_with_builds that controls whether test job statuses are updated together with their corresponding build job statuses. When set to false, while tests jobs are waiting for their corresponding build jobs to finish, their statuses remain in pending state and only build job statuses are updated. (packit-service#2470)sync_test_job_statuses_with_builds that controls whether test job statuses are updated together with their corresponding build job statuses. When set to false, while tests jobs are waiting for their corresponding build jobs to finish, their statuses remain in pending state and only build job statuses are updated. (packit-service#2470)propose_downstream failures by setting notifications.failure_issue.create in the configuration to false. (packit-service#2451)PACKIT_UPSTREAM_REPO and PACKIT_DOWNSTREAM_REPO (in case of propose_downstream and pull_from_upstream jobs), in the post-upstream-clone action. (packit#2327)allowed_pr_authors/allowed_committers configuration before running Koji production builds is now more reliable.\n(packit/packit-service#2435)propose-downtream for CentOS Stream. (packit#2318)dist-git init command from CLI, you can pass a command to specify the git URL of the project. (packit#2308)scan-in-osh subcommand in the CLI to perform a scan through OpenScanHub. By default it performs a full scan of the packages and a differential scan can be performed through --base-srpm option. (packit#2301)PACKIT_PROJECT_VERSION environment variable.\n(packit#2297)status_name_template option that allows you to configure\nstatus name for a Packit job. For further details have a look at our\ndocs.\nThis feature is still experimental and at the moment it is not possible\nto retry such jobs via GitHub Checks' re-run.\n(packit-service#2402)koji_build job has a new sidetag_group option that allows to perform a downstream Koji build in a sidetag.\nA new sidetag will be created for each configured dist_git_branch if it doesn't already exist.\nThis represents the first step towards multi-package Bodhi updates. Stay tuned for further advancements!\n(packit-service#2409)copr_build job status checks were sometimes wrongly updated with a misleading\nmessage after a SRPM build failure. (packit-service#2406)packit dist-git init now allows specifying --version-update-mask option and also any arbitrary top-level configuration options. (packit#2288)/packit test comment command: in case there is a missing build for some target, the build will not be triggered anymore, it will just be reported to the user. We needed to make this change as with the increased complexity of the configuration (multiple test jobs), the previous implementation was prone to race conditions leading to wasting of resources of Copr and Testing Farm. (packit-service#2399)copr_build jobs sharing a Copr project but having different targets were running at the same time. (packit#2274)manual_trigger: True. (packit-service#2389)The default behaviour of changelog entry generation has been changed to comply with Fedora Packaging Guidelines\n(see the relevant Fedora Packaging Committee discussion).\nFrom now on, the default changelog entry is \"- Update to version \\<version>\".\nUsers can still affect this behaviour using custom commands in the changelog-entry action\nor with the copy_upstream_release_description configuration option.\n(packit#2253)
\"[packit]\" prefix has been removed from default dist-git commit message titles in order to prevent\nunnecessary noise in autogenerated changelog. Users can override this using the commit-message action.\n(packit#2263)
packit validate-config now checks whether upstream_project_url is set if pull_from_upstream job is configured.\n(packit#2254)%prep section processing. For instance, if the %patches macro appeared there,\nit would have been converted to %patch es, causing failure when executing %prep later.\n(specfile#356)packit). (packit-service#2364)GitLabProject.get_file_content() can now correctly handle file paths starting with ./. (ogr#844)ignore for trigger in jobs configuration that indicates not to execute the job at all.\nThis can be useful for templates or temporarily disabled jobs. (packit#2234)Usage page in case of unsuccessful queries. (dashboard#378)/packit pull-from-upstream --with-pr-config --resolved-bugs rhbz#123. (packit-service#2346)packit dist-git init that initializes Packit configuration for release automation in dist-git repository. (packit#2225)require.label.present and require.label.absent. By configuring these you can specify labels that need to be present or absent on a pull request for Packit to react on such PR. (packit-service#2333)labels property for PullRequest and Issue now return list of PRLabel and IssueLabel respectively. (ogr#839)packit validate-config now checks whether the Upstream Release Monitoring for the package is correctly configured if pull_from_upstream job is present in the configuration. (packit#2226)parse_time_macros that allows to configure macros to be explicitly defined or undefined at spec file parse time. (packit#2222)pull-from-upstream and propose-downstream commands now have the --sync-acls option that enables syncing the ACLs between dits-git repo and fork. The default behaviour was, however, changed to not sync the ACLs. (packit#2214)allowed_pr_authors and allowed_committers now allow specifying groups and also aliases all_admins and all_committers (corresponding to the access to the repository). (packit-service#2320)/bodhi-updates for getting information about Bodhi updates submitted by Packit. (packit-service#2310)/packit test command, you can now also use -i and --id aliases for --identifier option. (packit-service#2309)koji_build and bodhi_update jobs.\nFor both of them, the behaviour is the same as for pull_from_upstream - the configuration is taken\nfrom the default branch of the dist-git repository (usually rawhide) and other branches are ignored.\n(packit-service#2295)Let's see what happened in Packit in 2023.
GitForgeInternalError rather than PagureAPIException when\ngetting 50x response from the Pagure API. This should increase usability as\nthose tasks will be retried.\n(ogr#762)srpm_build_deps defined are now built in Copr as well.\n(packit-service#1822)null as a Copr build for\nTesting Farm runs that do not require any Copr build.\n(dashboard#200)Specfile itself can now be copied using the standard\ncopy() and deepcopy() functions from copy module.\n(specfile#176)propose-downstream job on GitLab. (packit-service#1842, packit-service#1844, packit-service#1845, packit-service#1846)/packit create-update\nand /packit koji-update comments in an issue opened by Packit in the configured issue_repository if anything\nwent wrong during these jobs. (packit-service#1796)enable_net=False: our documentation stated this, but it\nwasn't the case. This is now corrected. (packit#1825)update_release: false in the configuration to tell Packit not to change the Version and\nRelease in the spec file. It works the same as --no-update-release (renamed from now deprecated --no-bump) in\nthe CLI. (packit#1827)module_hotfixes for Copr projects.\n(packit#1829)tf_extra_params config option.\nThe free-form dictionary must follow the structure of Testing Farm POST requests. See our documentation\nand examples for more information. (packit-service#1853)--srpm option with the packit build locally CLI command. (packit#1810)PACKIT_PROJECT_VERSION environment variable when running changelog-entry action. (packit#1853)packit validate-config CLI command now provides details about errors when it cannot parse the config file. (packit#1861)--update-release/--no-update-release CLI flag now affects only Release, not Version. (packit#1857)commit or release trigger.\nThis will prevent the collision of the names. (packit-service#1920)frozen). From now on, Fedora 38 updates will be created even when the release is frozen. (packit#1863)packit validate-config now correctly checks glob-patterns in 'files_to_sync' (packit#1865) and provides details about errors when it cannot parse a config file. (packit#1861)Thank you, @SpyTec for so many wonderful changes in our dasbhoard.
get_current_version action defined by the user to retrieve version before updating the specfile %setup macro (if any). (packit#1886)%autorelease during propose_downstream and pull_from_upstream. (packit#1904)packit source-git related commands can skip dist-git repos, where the git trailer is not found, when looking for the right dist-git dir where to work. (packit#1938)_packitpatch script in a more reliable manner that doesn't rely on deprecated setuptools functionality. (packit#1926)propose_downstream. (packit#1939)Release field in dist-git spec file to 1 when the version in upstream spec file is not up-to-date with the release that triggered propose_downstream. (packit#1940)pyproject.toml. (packit#1913)upstream_ref for tags that start with \"a\", \"b\", \"c\", \"e\", \"n\", \"r\", \"s\". (packit#1943)%autorelease usage in dist-git spec file during propose-downstream and pull-from-upstream has been improved and Packit will always preserve it. (packit#1949)commit trigger. (packit-service#2015)propose-downstream job triggered by an issue comment now correctly loads the configuration from the upstream repository. (packit-service#2021)We have experienced issues with automatic Bodhi updates that we are investigating.\nIn case you miss a Bodhi update, you can\nretrigger the job via /packit create-update\ncomment in a dist-git pull request.\nBesides that, during this short week (another Czech Republic public holiday) we didn't manage to implement\nany significant new features.
follow_fedora_branching.\nAlready existing projects are not affected by this change and it is also not enforced with the custom Copr repositories. (packit#1970)artifacts in the tf_extra_params dictionary will be now combined with the artifact passed by Packit instead of rewriting it. (packit-service#2056)%changelog sections. (specfile#230)branch is specified in the particular job configuration. (packit-service#2074)manual_trigger in the configuration that allows you to make jobs run only when explicitly triggered by a comment. (packit-service#2069)Our dashboard now shows projects in a table instead of the cards.\n(dashboard#267)
/packit test command has two new options:
With --identifier option, Testing Farm will trigger only jobs with that identifier.\n(packit-service#2079)
Also, it is now possible to specify labels for a job and trigger tests based on labels\nusing a --labels option of the /packit test command.\n(packit#1988,\npackit-service#2088)
If the vm_image_build job doesn't have Copr project/owner configured,\nCopr project used for the latest Copr build of the pull request will be now used.\n(packit-service#2080)
Fixed filters in files_to_sync not being applied properly.\n(packit#1977)
The issue that could've caused inconsistencies when tests from a PR\nwere supposed to be merged during the test runs on the Testing Farm has been fixed.\n(packit-service#2090)
Packit now includes dist-git branch in the title of the PRs for propose-downstream and pull-from-upstream.\n(packit#1996)
Many dashboard issues have been fixed during the\nContribute to an Open Source Service\nworkshop at DevConf.CZ.\nStef Walter,\nErik Gustavsson,\nRoman Braunstingl,\nJaroslav Reznik,\nChristophe de Dinechin,\nGris Ge\nand David Duncan,\nthank you for your contribution!\n(dashboard#291,\ndashboard#292,\ndashboard#293,\ndashboard#294,\ndashboard#295)
pull_from_upstream jobs can now be retriggered with a comment\n/packit pull-from-upstream in a dist-git pull request.\n(packit-service#2087)pre-sync action. (packit#2006)%prep macros in our specfile library. For instance, when a quoted\nstring appeared inside an expression expansion, it could lead to improper parsing, rendering the spec file invalid\nafter accessing the options. (specfile#253)upstream_tag_include and upstream_tag_exclude. They should contain a Python regex that can be used as an argument in re.match. (packit#2030, packit-service#2138)pull-from-upstream via a comment will now use the correct configuration file from the default dist-git branch. (packit-service#2140)pull-from-upstream job can now be used with upstream repos that are not hosted on a supported git forge. (packit-service#2137)packit source-git init caused by the changed behaviour in the newer version of rpmbuild. (packit#2048)valid attribute. A macro definition/tag is considered valid if it doesn't appear in a false branch of any condition appearing in the spec file. (specfile#276)PACKIT_PACKAGE_NAME, PACKIT_UPSTREAM_PACKAGE_NAME and PACKIT_DOWNSTREAM_PACKAGE_NAME env variables to all the actions. (packit#2061)PACKIT_UPSTREAM_REPO and PACKIT_DOWNSTREAM_REPO environment variables for release syncing actions. The variables represent paths where the respective git repositories are cloned (packit-service#2166)Project views on our dashboard. (packit-service#2165)commit-message action that can be used to override the default commit message produced by Packit during propose-downstream or pull-from-upstream. Please pay attention to our documentation with regards to the usage of this action. (packit#2070)pull-from-upstream workflow.\nUse the packit pull-from-upstream command from the packit RPM package. (packit#2063)initiator context for tmt to the Testing Farm. You can use this option to run or skip certain tests when they're run by Packit. (packit-service#2176)get_fork method for Pagure about checking the usernames for a match when going through existing forks. (ogr#800)upload_sources to False to disable this. (packit#2086)notifications.failure_comment.message that enables notifying users on failure via a comment using the configured message. (packit-service#2182)pkg_tool option in the config\n(at the top-level or with specific packages when using the monorepo syntax).\nThis option can be used for switching between fedpkg or centpkg.\n(packit#2085)Version tag during propose_downstream or pull_from_upstream,\nPackit now tries to update referenced macros (if any) rather than overwriting the references.\n(packit#2087)-b or --resolve-bug option for propose-downstream and pull-from-upstream commands. The values will be added by default to the changelog and commit message and provided in commit-message and changelog-entry actions as PACKIT_RESOLVED_BUGS env variable. (packit#2094)- Resolves {bugzilla} to the changelog (or commit if autochangelog is used) and provides the value in commit-message and changelog-entry actions as PACKIT_RESOLVED_BUGS env variable. When retriggering the pull-from-upstream from comment, one can also specify the bug(s) as /packit pull-from-upstream --resolved-bugs rhbz#123,rhbz#125 and Packit will do the same. (packit-service#2193)notifications.failure_comment.message also for downstream jobs, where the configured message will be used as an extension of the comment added by default by Packit. (packit-service#2199)PACKIT_UPSTREAM_PACKAGE_NAME, PACKIT_DOWNSTREAM_PACKAGE_NAME and PACKIT_CONFIG_PACKAGE_NAME also in the changelog_entry action. (packit#2103)packit.json or .packit.json as a configuration file name.\n(packit#2123)%autochangelog.\n(packit#2126)/packit test comment command if the last build was not successful.\n(packit-service#2228)And special thanks to @SpyTec\nfor multiple wonderful dashboard improvements!
%{?dist}) is now enforced when updating release during SRPM creation. (packit#2106)~^+ (special characters) in a tag (used for building the version string). (packit#2154)/jobs/downstream-koji-builds on dashboard and are also accessible via /api/koji-builds API endpoint. (packit-service#2244, packit-service#2249, dashboard#354)propose_downstream and pull_from_upstream.\nA spec file update might be required, see the documentation for more details.\n(packit#2149)Specfile.update_version(), that allows updating spec file\nversion even if it is a pre-release. (specfile#317)update_version_mask configuration option, that the proposed version of new release\nand the current version of the dist-git branch are compatible and sync the dist-git branch only in that case.\n(packit#2156)Version tag is not present in the specfile directly,\nbut e.g. imported from another file. (packit#2157)PACKIT_COPR_PROJECT env var that is exposed to Testing Farm now includes the Copr project of the additional build\nspecified in comment, if present. (packit-service#2253)Packit now links the information related to upstream events in PRs opened when syncing a release.\n(packit#2173)
When accessing tags or macro definitions by name, specfile library now takes validity into account\nwhen looking for the best match. For example if there are two instances of Version tag,\none in the true and one in the false branch of a condition, Specfile.version will always access\nthe one that is in the true branch.\nThis also applies to Packit when syncing a release and updating value of Version tag.\n(specfile#328)
We have introduced new configuration options test_command.default_labels and test_command.default_identifier that are used by default when running /packit test comment command without any arguments (instead of specifying them via --labels/--identifier). (packit-service#2270)
We have fixed a bug that GithubRelease.url returned an API URL. (ogr#824)
pull-from-upstream jobs that have sources hosted at infradead.org, sourceforge.net and gitlab.gnome.orgWe, the packit team, are happy to invite you to our upcoming workshop about pulling upstream releases to Fedora using Packit.
When: Wed, Jan 10, 9:30 AM - Wed, Jan 10, 12:30 PM (GMT+1)
Where: Online!
Who should attend: Anyone who maintains a package in Fedora or EPEL and would like to automate syncing the upstream releases for it. The automation is most suitable for simple packages with straightforward update processes (e.g. without patches, or need to build in side-tags). It works without access to the upstream repository.
No package? It’s not an issue. The workshop can help you understand the Fedora release process and the services involved. During the workshop, you can help someone else automate their package or ask someone around if you can help with the maintenance (that’s usually very welcome!). You can also bring an orphaned package back to life!
Can’t make it this time? You can also follow our documentation and ask for help in case of any issue: #packit:fedora.im (Matrix).
If you want to join us please fill this form or contact us on Matrix, and we will send you further details!
Looking forward to seeing you!
", "url": "https://packit.dev/posts/weekly/2023/packit-workshop", "title": "Packit workshop - Fedora Community Edition", "summary": "We, the packit team, are happy to invite you to our upcoming workshop about pulling upstream releases to Fedora using Packit.", "date_modified": "2023-12-05T00:00:00.000Z", "author": { "name": "Maja Massarini", "url": "https://github.com/majamassarini" }, "tags": [ "2023-December", "2023", "December" ] }, { "id": "https://packit.dev/posts/weekly/2022", "content_html": "Let's see what happened in Packit in 2022.
target_branch_head_commit property to the PullRequest class in ogr that allows\nyou to get commit hash of the HEAD of the target branch (i.e. base, where the changes are merged to).\n(packit/ogr#671)PACKIT_TARGET_SHA variable, which holds commit hash of the HEAD of the target\nbranch where the changes are supposed to be merged, to the Testing Farm environment. This should\nhelp solving the issue of running tests from non-merged codebase on the Testing Farm side.\n(packit/packit-service#1319)--no-bump and --release-suffix options for\nsource-git repos.\npackit/packit#1452pr/{pr_id} when checking out a PR, even when\nit's not being merged with the target branch. This results into NVR of the\nbuild containing pr{pr_id} instead of pr.changes{pr_id}.\npackit/packit#1445%changelog sections in dist-git using the %autochangelog macro are\npreserved when running\npropose-downstream, except when sync_changelog is set to true..git\nto be a file with a gitdir\nreference, not only a directory.propose-downstream job, we create\na README.packit file with some info about the sync the packit version used.\nTo avoid this you can add create_sync_note: false to conig file.\npackit/packit#1465--no-require-autosetup for source-git init command has been\nintroduced. Please note that source-git repositories not using %autosetup may\nnot be properly initialized. (packit#1470)/packit rebuild-failed and similarly for testing farm: /packit retest-failed.\n(packit-service#1303)files_to_sync. Key sync_files is now deprecated.\n(packit#1483)\n(packit.dev#390)python3-setuptools_scm is now available by default in the sandbox.srpm_build_deps, in the packit configuration filespecfile_path and\ndownstream_package_name are not set, Packit now correctly resolves this\nsituation and sets specfile_path to the name of the upstream repo suffixed\nwith \".spec\".\n(packit#1499)packit source-git status has been introduced for checking\nthe synchronization of a source-git and a dist-git repository based on the\nused git trailers. The command outputs a range of commits which need to be\nsynchronized from dist-git to source-git or the other way around. If possible,\nthe command also provides instructions on how to synchronize the repositories.\n(packit#1500)enable_net configuration option for Copr builds that\nallows you to disable network access during Copr builds. It is also complemented\nby --enable-net/--disable-net CLI options if you use Packit locally.\n(packit#1504)/packit command\n(packit-service#1372)PACKIT_SOURCE_SHA, PACKIT_TARGET_SHA, PACKIT_SOURCE_BRANCH,\nPACKIT_TARGET_BRANCH, PACKIT_SOURCE_URL and PACKIT_TARGET_URL.\nThese variables are not set for test runs of releases and branch pushes.\n(packit-service#1382)rawhide or main when configured\nto do Koji builds for rawhide.\n(packit#1393)fas_username and fas_password in your Packit user config\nto not be asked about that when the command is executed.\nAlso, this allows Packit GitHub application to use this as well\nso you can look forward to Bodhi updates created by Packit\n(will be announced and described in a dedicated post).\n(packit#1517)Packit <hello@packit.dev>.\n(packit-service#1410)packit_instances key that you can use to specify the Packit\ninstances you want to use for working on your jobs. Nothing will change for our\nproduction users, but users of our stage instance need to use this key to\npreserve the support of the stage instance -- they can set both stg and prod in\nthe packit_instances list to use both, or use just one. Just be careful with\nthe downstream jobs where both instances work with the same services.\nThis new option works like other Packit options so you can set it on the top\nlevel and/or (re)define it on the job level.\nMore information about our staging instance can be found here:\npackit#1530.\n(packit#1417)get_contributors function in ogr that can be used for getting contributors to the project on GitHub (set of logins) and GitLab (set of authors).\n(ogr#692)packit.yaml) is now working properly again.\n(packit#1532)packit source-git update-dist-git and packit source-git update-source-git now check the synchronization of source-git and dist-git repositories prior to doing the update. If the update can't be done, for example, because the histories have diverged, the command provides instructions on how to synchronize the repositories.\nA --force option is available to try to update the destination repository anyway.\n(packit#1534)post_upstream_clone to generate your spec-file,\nPackit now correctly checks out a release before the action is run.\n(packit#1542)fedora-latest-stable resolves to the latest stable Fedora\nLinux release, while fedora-branched resolves to all branched releases (all Fedora Linux release, except rawhide).\n(packit#1546)/packit-stg comment commands so you can now differentiate\nbetween the instances when commanding Packit via pull-request or issue comments.\nFor the production instance, you can continue using /packit prefix as you are used to.\n(packit-service#1432)downstream_branch_name has been added, which is meant to be used in source-git projects\nand allows users to customize the name of the branch in dist-git which corresponds to the current source-git branch.\n(packit#1555)revision-range argument of the source-git update-source-git command is now optional. If not specified,\ndist-git commits with no counterpart in source-git are synchronized.\n(packit#1547)source-git update-* commands now check whether the target repository is pristine and in case not raise an error.\n(packit/packit#1562)propose-downstream jobs.\n(packit-service#1461)issue_repository in your Packit config file, Packit will create an issue in that project and link the dist-git page where you can give Packit FAS user the correct permissions.\n(packit-service#1465)PACKIT_PR_ID environment variable to the Testing Farm.\n(packit-service#1467)commit trigger.\n(packit-service#1474)release event with correct NVR (without the artificial release suffix). You can use it for distributing RPM packages via Copr.create_pr option for our service, from now on Packit will unconditionally create PRs when running propose-downstream.\nWe have also updated the propose-downstream CLI such that it is possible to use create_pr from configuration or override it via --pr/--no-pr options.\n(packit#1563)release_suffix configuration option that allows you to override the long release string provided by Packit that is used to ensure correct ordering and uniqueness of RPMs built in Copr.\n(packit#1568)packit source-git commands learnt to replace Git-trailers in commit messages if they already exist. (packit#1577)packit source-git init when the preamble does not contain blank lines. (packit#1582)--release-suffix parameter in all of the related CLI commands. Also we have added a support for the release_suffix option from configuration to the CLI. With regards to that we have introduced a new CLI switch --default-release-suffix that allows you to override the configuration option to Packit-generated default option that ensures correct NVR ordering of the RPMs. (packit#1586)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)/packit verify-fas. You can find more info in our requirements. (packit-service#1487)allowed_pr_authors or allowed_committers in the job metadata (see the documentation). (packit-service#1520)targets and dist_git_branches configuration keys were not accepted.\n(packit#1608)skip_build option is enabled.\n(packit-service#1539)propose-downstream is now made more obvious in logs.\n(packit#1626)propose-downstream is now made more obvious in logs. (packit#1626)propose downstream results in our dashboard. (packit-service#1553)tmt_plan and tf_post_install_script in the\nconfiguration. (packit#1659)python-specfile library for handling spec files. This may cause some issues to pop up. (packit#1588)/packit koji-build into a dist-git pull request with target branch corresponding to the branch the build should be acted upon. (packit-service#1586)fix_spec_file can change a spec file - Packit now preserves that change.\n(packit#1679)downstream_package_name is set, and\n<downstream_package_name>.spec can be used as the specfile_path.\n(packit#1663)--wait / --no-wait options.\n(packit#1666)prepare-sources command now has a --create-symlinks / --no-create-symlinks option,\nwhich enables copying the archive instead of symlinking. This will be used in the Copr environment,\nwhere symlinking the archive previously caused issues.\n(packit#1682)packit propose-downstream is now more informative when sources cannot be\ndownloaded. (packit#1698)srpm_build_deps config option to use Copr as a builder.\nLet us know if you hit any issue with the new implementation. We are going to slowly decommission the old implementation\nand are happy to help with the transition. (packit-service#1636)https://example.com/foo/1.0/download.cgi#/%{name}-%{version}.tar.gz (specfile#100)Packit allowed forge projects in the Copr projects, the link for the group projects is now correct. (packit-service#1680)build job type name has been deprecated. It aimed to be an alias when Packit supported just one build type.\nThere are currently more types of builds and just build can be misleading. Please, be explicit and use copr_build instead.\nThe production_build name for upstream Koji build is misleading because it is not used to run production/non-scratch\nbuilds and because it can be confused with the koji_build job that is triggered for dist-git commits.\n(The koji_build job can trigger both scratch and non-scratch/production builds.)\nTo be explicit, use upstream_koji_build for builds triggered in upstream and koji_build for builds triggered in downstream.\nUsers will get a neutral status describing the change when the old names are in use. The status will become a warning\nstarting in November and the old names will be removed by the end of the year. (packit-service#1656)--no-bump flag was specified.\nAlso fixed an issue when None appeared in release instead of a number.\n(packit#1753)specfile_path was not specified, and specfile_path was always set to <repo_name>.spec. (packit#1758)/packit create-update. (packit-service#1729)release_suffix configuration option is empty. (packit-service#1738)specfile parser now supports localized tags (e.g. Summary(fr)) and tags with qualifiers (e.g. Requires(post)). (specfile#132)srpm_build_deps can be now configured also on the job configuration level. (packit-service#1757)build alias of copr_build and production_build replaced by upstream_koji_build) newly lead to an error state (was neutral ) of the deprecated status created by Packit.\nThe old names will be removed by the end of the year. (packit-service#1777)packit propose-downstream now uploads all remote sources (those specified as URLs) and the\nsource specified by spec_source_id (whether remote or not) to lookaside. Previously, only Source0\nwas uploaded. Source0 is no longer treated specially, but as spec_source_id is Source0 by default,\nSource0 is still being uploaded by default unless spec_source_id is overriden.\n(packit#1778)/packit vm-image-build (the job needs to be defined in the configuration).\nThis feature is experimental and is still being tested.\n(packit-service#1761)Section and Tag objects in specfile library now have normalized_name property for more convenient comparison.\nThere is a new method, Specfile.get_active_macros(), to get active macros in the context of the spec file.\nThe underlying rpm.spec instance is now exposed as Specfile.rpm_spec property.\nThere is a new utility class for parsing NEVRA strings. (specfile#141)Release tag during propose-downstream if the version\nis updated and the Release tag has not explicitly been overridden in the\nupstream specfile.\n(packit#1801)srpm_build_deps to be sure that we don't break your workflow once\nwe switch to building all SRPMs in Copr in January.\n(packit-service#1804)Specfile.sections(), Specfile.tags() etc.) can now be nested\nand combined together (with one exception - Specfile.macro_definitions()), and\nit is also possible to use tag properties (e.g. Specfile.version, Specfile.license)\ninside them. It is also possible to access the data directly, avoiding the with\nstatement, by using the content property (e.g. Specfile.tags().content), but\nbe aware that no modifications done to such data will be preserved. You must use\nwith to make changes.\n(specfile#153)Specfile instances, making it possible\nto work with more than one Specfile instance at a time.\n(specfile#157)Let's see what happened in Packit in 2021.
propose-downstream.\npropose-update is now deprecated. (packit#1065, packit-service#913)Testing farm is temporarily disabled. status until we have the new runner available.\n(packit-service#929)master.\n(packit#1074,\npackit-service#924)propose-downstream on source-git repositories now always uses --local-content.\n(packit#1093)master to main.--koji-target option of the CLI's build command now accepts aliases.\n(packit#1052)--dist-git-branches option in the CLI's propose-downstream command was\nfixed, it now respects set branches.\n(packit#1094)packit init command now works with CentOS packages.\n(packit#1106)create-update to work with EPEL and add password prompt.\n(packit#1122,\npackit#1127)build + test jobs, kudos to Laura.\n(packit-service#996)sources which overrides the URLs defined in specfiles.\n(packit#1131, packit#1143)packit to detect if patch-files generated from\nGit are identical with the ones already in dist-git. This should help\navoiding superfluous changes done by propose-downstream. (packit#1133)propose-downstream job. This\nshould give more time for the sources to become available after a release is\ncreated. (packit-service#1019)packit init CLI command has been updated to.distro instead of fedora.\n(packit#1165)centos-stream target is temporarily resolved to centos-stream-8 to reflect a change in Copr.\n(packit#1167)packit push-update\n(packit#1191).fedora-latest alias for build and test targets, which\nresolves to the latest branched Fedora Linux\n(packit#1187).packit.yaml) can be specified\nusing a new, top-level -c, --config option\n(packit#1184).packit init\n(packit#1206).current_version_command and create_tarball_command config options are being deprecated\nin favour of actions.\nAn issue will be created in the affected repositories if we find those options in use.\n(packit-service#1064)/packit commands only when they appear alone on a line\n(packit-service#1065,\npackit-service#1083).current_version_command and create_tarball_command in packit config\n(packit#1212).fedora-latest alias\n(packit#1222).update-dist-git command to specify the packaging tool (e.g. centpkg).\nBy default, fedpkg is used.\n(packit#1257,\npackit-service#1105).patch_id in the metadata of source-git commits.\n(packit#1252)propose-downstream caused an upstream git repository to be dirty,\nthe sync for other branches failed. (packit-service#1111)packit generate is not supported anymore. (packit#1269)source-git to group source-git related commands\ninit and update-dist-git. (packit#1273)submitted_time to the test result.\n(packit-service#1113)packit source-git init: CLI is now more\nstreamlined and simplified, and the command produces source-git repos\nmatching [our documentation]({{< ref \"create-source-git.md\" >}}).\n(packit#1277)Upstream class - should not have\nimpact on our users, but make the code easier to work with.\n(packit#1157)source-git init's CLI.\n(packit#1284)Summer is here and vacations with it. Most of the work done in this sprint\nis either internal (not user facing) or not finished yet.
/packit test.\n(packit-service#1132)Checks tab.\nThis gives us more options like status with a neutral state\n(e.g. currently, for permission errors) or a place for showing more details.\nDon't forget to give our GitHub application permissions to use it.\nYou can expect more improvements in this field.\n(packit-service#1167)squash_commits key is deprecated. Instead of using this,\nset the same patch_name in the commit\nmessage of adjacent commits, which should end up in the same patch file.\n(packit#1309)packit init can now find a spec file inside of a git repository and set\nit in .packit.yaml. (packit#1313)sync_release in API allows specifying a suffix for the newly created branch in a dist-git repo fork,\nso that there can be more open update PRs for the same dist-git branch at the same time.\n(packit#1326)/packit test comment was improved.\nIf there is no existing Copr build when the tests are triggered,\nPackit service should now react and create a new build.\nAlso when the last Copr build status is failed,\ntests are not submitted and users are informed about this.\n(packit-service#1188)oraclelinux-7/oraclelinux-8 chroots for build and test of your package on Oracle Linux.\n(packit-service#1186)status command of Packit's CLI has been refactored and now provides much cleaner output. (packit#1329)/packit test, Packit service sets a status before starting the job\nto unify the behaviour with reacting to triggering builds. (packit-service#1187)packit validate-config now checks also the value of the specfile_path configuration option\nand shows warning if the specified file is not present in the repository. (packit#1342)source-git update-dist-git now supports using Git trailers to define patch metadata,\nwhich will control how patches are generated and added to the spec-file.\nsource-git init uses this format to capture patch metadata when setting up\na source-git repo, instead of the YAML one.\nTo maintain backwards compatibility, the YAML format is still parsed,\nbut only if none of the patches defines metadata using Git trailers.\n(packit#1336)propose-downstream was fixed.\nNew behavior preserves downstream changelog and in case there are either\nno entries or no %changelog section present, it is created with a new entry.\n(packit#1349)packit source-git init was updated to try to apply patches with git am first, and use patch only when this fails, in order to keep the commit message of Git-formatted (mbox) patch files in the source-git history. (packit#1358)PACKIT_RPMSPEC_RELEASE environment variable in actions. (packit#1363)rpm has been\nfixed./packit _ commands, our bot gives\nyou a 👍 reaction to let you know that we are working on it.-b or --resolve- bugzillas and specify IDs (separated by comma, e.g.\n-b 1 or -b 1,2,3) of bugzillas that are being closed by the update.\n(packit#1383)aarch64 architecture in the Testing Farm.\n(packit-service#1247)centos-6 target.\n(packit-service#1244)--no-bump that prevents changing of the release in the SRPM,\nwhich can be used for creating SRPMs on checked out tags/releases.--release-suffix that allows you to customize the suffix after the release number,\ne.g. reference bugzilla or specific branch of the build.merge_pr_in_ci that allows you to disable merging of PR into the base branch before creating SRPM in service. (packit#1395, packit-service#1261)packaging/fedora/pkg.spec), it is now correctly synced to the root of\nthe downstream repository, since that's where rpmbuild will look\nfor it. (packit#1402)current_version_command and create_tarball_command have been removed and are no longer supported. They are superseded by actions get-current-version and create-archive. (packit#1397)UnicodeEncodingError, when working with\ndist-git patch files with an encoding other than UTF-8.\n(packit#1406)skip_build option in the test job metadata in the\nPackit configuration file. This will cause no Copr build to be built and\ninstalled into the testing environment, but only trigger the tests in\nTesting Farm (the selected components to be installed should be part of the\nTMT definitions).\n(packit-service#1256)changelog-entry action that is used when creating SRPM.\nThe action is supposed to generate whole changelog entry (including - at\nthe start of the lines) and has a priority over any other way we modify the\nchangelog with. (packit#1367)env config option has been added for specifying environment variables,\nwhich are then passed to Testing Farm along with some more pre-defined\nvariables (e.g. name of the project, URL, etc).\n(packit#1411)\n(packit-service#1275)koji_build job using the commit trigger to submit a\nKoji build for a new commit in a dist-git branch. The configuration file\nneeds to be present in the dist-git for now\n(the state for the new commit is used).\n(packit-service#1278)/packit test comment to run\nthe job.\n(packit-service#1302)\n(packit-service#1305)packit prepare-sources command has been implemented for preparing\nsources for an SRPM build using the content of an upstream repository.\n(packit#1424)upstream_package_name config option is now checked for illegal\ncharacters and an error is thrown if it contains them.\n(packit#1434)Let's see what happened in Packit in 2020.
Both Packit and Packit Service pre-commit hooks were updated to include\nprettier and setup-cfg-fmt, in order to have a more consistent formatting of\nmarkup, YAML, JSON and setup.cfg files.
It became easier for developers to build the Packit base image locally, and\ntests in Zuul were configured to run on Fedora 31.
Packit learned how to look for RPM spec files on its own, so specifying\nspecfile_path in the configuration is not mandatory anymore. Packit will\nrecursively search the tree and use the first spec file found.
The Redis pod in Packit Service uses an up to date image now, based on Fedora 31.\nKudos to hhorak for the help!
The default configuration generated by Packit has test jobs enabled from now\non. This should simplify configuring Packit in new repositories.
Fixed a bug which was causing SRPM-build failures in Packit Service for projects\nwhich had their spec files stored in a subdirectory.
As a result of keys.fedoraproject.org being turned off, Packit now tries a\nlist of GPG keyservers when downloading keys to check commit signatures.
When enabling Packit Service for new GitHub repositories, instead of checking\nif the requester is a Fedora packager, we'll check if they signed the Fedora\nProject Contributor Agreement.
While proposing an update to Fedora, Packit Service will report a failure now\nwhen there are no releases found in the upstream GitHub repository.
Test results became serializable, we will not block when no test results\nare received, and Packit Service received some initial code to enable using\nPostgreSQL as a data backend.
Postgresql database was introduced in production environment to improve performance and enable implementation\nof new features, e.g. storing logs to reduce amount of messages sent directly to pull request (#406), (#420).
Cleanup in configuration files was performed, so no longer needed values were removed from .packit.yaml (#709).\nUser experience was improved by adding new --upstrem-ref option to copr-build command in command-line interface (#718)\nand making error reporting more robust by adding new fedpkg clones related error message (#714).
Following bugs were fixed:
-p1 to resolve an issue when they are generated with git and patch program fails to apply them (#730).targets key in copr job definition in the packit.yaml is no longer a required field (it defaults to fedora-stable) (#431).notifications: {pull_request: {successful_build:: false}} in your packit.yaml), hi\nLars! (#455).git-describe output better which should help when tags\ncontain dashes (#759).propose-update in the issue\nwhich triggered the update now include the URL of the new pull-request in Fedora (#472).copr-build command, you do not\nneed to set the project name if this value is defined in\nthe copr_build job in the configuration file (#763).authentication key in the configuration (#754).Propose-update triggered by comment in GitHub now recognizes also pre-releases (#498).Source and creates .tar.gz by default - this should be more flexible and prevent issues for \"non-standard\" archive names. (#781)packit srpm to linearise extremely complex Git\nhistories, in order to get patches that can be applied when building the\nSRPM.packit in Fedora 32 and Rawhide.dist-git-branch is now marked as deprecated, to be\nreplaced by dist_git_branches to match the naming of other metadata fields\nand to accept multiple branch names where Packit should work. (#797,\n#788 and #564).In this week we mostly focused on CentOS Stream and\nsome under the hood improvements,\nnone of which are available for GitHub projects.
propose-update causing problems with the synchronization of the spec-file content was fixed. (#830)epel-all alias in the arguments and also in the configuration. (#835)epel-all alias as well. (#835)/packit test.\nNow, we trigger the build first if there are no builds for the pull-request yet. (#631)Hello everyone, during this week we didn't manage to implement any significant new features - most of the work happened under the hood.
bash -c required (by @TomasTomecek, #871).packit validate-config which validates the contect of a package configuration file in your project\n(contributed by @TomasJani, #826).validate-config works properly now and does not produce odd error messages, by @TomasTomecek and @csomh, #894 and #895%release field in spec file when using srpm command, by @TomasTomecek, #894/api/projects/, by @IceWreck, #716 Copyright (c) Dominika Hodovska. This work is licensed under a Creative Commons Attribution 4.0 International License.
packit.\nThat user had been inactive for a long time and Hunor's request was successful./api/srpm-builds/ endpoint./api/srpm-builds endpoint.\n(packit-service#788)/koji-builds endpoint to be more consistent with /copr-builds endpoint (packit-service#791).test job also on Pagure and GitLab thanks to that.pkg_name-v1.2.3), it is possible to use upstream_tag_template to extract version from the tag, which will be used in a subsequent task. doc packit#959--remote is global option now and available for all commands. Because of this sync-from-downstream --remote was renamed to --remote-to-push. Remote can now be specified in the user's config (via upstream_git_remote parameter). packit#977Following bugs were fixed:
%setup line in a spec file - you are now able to set content of -n option via archive_root_dir_template config option, it defaults to {upstream-pkg-name}. doc packit#834Nothing significant happened during this week. The only change was that Hunor\nresolved a problem when sentry client library (the alert service we use) caused errors in stage\nenvironment and hence the problem didn't make it to production.
We have also released a new version of packit: 0.18.
We finally had a week with plenty updates!
scratch: true for koji builds before this gets resolved.sync_changelog which bypasses this behaviour and\ncopies the %changelog from upstream and overwrites the downstream changelog.\nPlease use this option only when your changelogs are in sync. DocumentationNo user-facing changes in packit(-service) this week.
propose-update. Also the default message has been changed\nto the list of commit messages from last release. (packit#1004)sync_release method of Packit API. (packit#1043)--upstream-url option of packit init command. When specified,\ninit also sets up a source-git repository next to creating a configuration file.Let's see what happened in Packit in 2019.
We would like to announce general availability of the initial version of\npackit, titled '0.1.0'.
Since this is our first release, we would like to ask you to be patient if you\nencounter any issues. We work hard on packit's usability. If you feel like that\npackit is doing something weird or if anything is unclear, don't hesitate and\nreach out to us by creating a new GitHub\nissue.
The initial release contains two commands:
packit propose-update — Opens a pull request in dist-git for the latest\nupstream release of a selected repository.packit watch-releases — Watches events for all the upstream releases and\nperforms propose-update for those who use packit.$ dnf install --enablerepo=updates-testing packit
Or
$ pip3 install --user packitos
Or (if you're brave)
$ pip3 install --user git+https://github.com/packit-service/packit
Present features have strict requirements on the upstream projects:
You need to have a packit config file present in the upstream repo.
You need to have spec file present in the upstream repo.
This workflow is suitable for people who are both upstream and downstream\nmaintainers of the particular project. If you don't fit into that bucket, then\npackit might not be ready for you, yet. Please wait till we land more\nsource-git\nrelated functionality into packit.
propose-updateI'm going to demonstrate this functionality on\nogr, our library for git forges,\nwhich powers packit.
It was recently approved for Fedora, so we can use packit to bring the initial\nversion of ogr into Fedora Rawhide, 30 and 29.
Let's see guide for\nthe propose-update command on what we need:
$ git remote -v
origin git@github.com:TomasTomecek/ogr.git (fetch)
origin git@github.com:TomasTomecek/ogr.git (push)
upstream https://github.com/packit-service/ogr.git (fetch)
upstream https://github.com/packit-service/ogr.git (push)
Yup.
$ git tag --list
0.0.1
0.0.2
0.0.3
$ git checkout 0.0.3
Note: checking out '0.0.3'.
And the tag name is matching the version in a spec file:
$ grep Version python-ogr.spec
Version: 0.0.3
$ ll .packit.yaml
-rw-rw-r--. 1 tt tt 177 Mar 1 17:44 .packit.yaml
Check.
$ ll python-ogr.spec
-rw-rw-r--. 1 tt tt 1.3K Mar 1 17:43 python-ogr.spec
👍
$ env | grep TOKEN
PAGURE_USER_TOKEN=will
PAGURE_FORK_TOKEN=not
GITHUB_TOKEN=share, sorry
$ kinit ttomecek@FEDORAPROJECT.ORG
Password for ttomecek@FEDORAPROJECT.ORG:
$ klist
Ticket cache: KEYRING:persistent:1024:krb_ccache_g0t1Ty3Ah
Default principal: ttomecek@FEDORAPROJECT.ORG
Valid starting Expires Service principal
03/01/2019 18:12:25 03/02/2019 18:12:19 krbtgt/FEDORAPROJECT.ORG@FEDORAPROJECT.ORG
renew until 03/08/2019 18:12:19
We're all set!
We are still in the \"ogr\" upstream git repository.
$ packit propose-update
INFO: Running 'anitya' versioneer
ERROR: Failed to determine latest upstream version!
Check that the package exists on https://release-monitoring.org.
using \"master\" dist-git branch
syncing ./python-ogr.spec
INFO: Downloading file from URL https://files.pythonhosted.org/packages/source/o/ogr/ogr-0.0.3.tar.gz
100%[=============================>] 17.95K eta 00:00:00
downloaded archive: /tmp/tmp2e65b0xt/ogr-0.0.3.tar.gz
uploading to the lookaside cache
PR created: https://src.fedoraproject.org/rpms/python-ogr/pull-request/1
Mind-blowing, isn't it? Now we have latest python-ogr in Fedora Rawhide by\nrunning only a single command.
I have also added ogr into release-monitoring as packit suggests.
Once we are okay with the changes, we have to merge the pull\nrequest. That's\nour responsibility, as maintainers.
Time to build the package (packit doesn't support building in koji, yet)
$ fedpkg clone python-ogr
Cloning into 'python-ogr'...
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 8 (delta 0), reused 5 (delta 0)
Receiving objects: 100% (8/8), done.
$ cd python-ogr
$ git log
commit c298df5e540ba1d010366e102c1c75d4f5b0b0cc (HEAD -> master, origin/master, origin/HEAD)
Author: Tomas Tomecek <ttomecek@redhat.com>
Date: Fri Mar 1 18:15:00 2019 +0100
[packit] 0.0.3 upstream release
more info
Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
commit 7d5ab1471ca0ee2a6c0254410b83beaa83b80f0b
Author: Gwyn Ciesla <limb@fedoraproject.org>
Date: Fri Mar 1 15:18:34 2019 +0000
Added the README
Yup, that's our commit. more info was added there by accident, this is\nalready fixed in packit.
$ fedpkg build
Building python-ogr-0.0.3-1.fc31 for rawhide
Created task: 33125435
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=33125435
Watching tasks (this may be safely interrupted)...
33125435 build (rawhide, /rpms/python-ogr.git:c298df5e540ba1d010366e102c1c75d4f5b0b0cc): free
33125435 build (rawhide, /rpms/python-ogr.git:c298df5e540ba1d010366e102c1c75d4f5b0b0cc): free -> open (buildvm-14.phx2.fedoraproject.org)
33125451 buildArch (python-ogr-0.0.3-1.fc31.src.rpm, noarch): open (buildvm-14.phx2.fedoraproject.org)
33125436 buildSRPMFromSCM (/rpms/python-ogr.git:c298df5e540ba1d010366e102c1c75d4f5b0b0cc): closed
33125435 build (rawhide, /rpms/python-ogr.git:c298df5e540ba1d010366e102c1c75d4f5b0b0cc): open (buildvm-14.phx2.fedoraproject.org) -> closed
0 free 1 open 2 done 0 failed
33125464 tagBuild (noarch): closed
33125451 buildArch (python-ogr-0.0.3-1.fc31.src.rpm, noarch): open (buildvm-14.phx2.fedoraproject.org) -> closed
0 free 0 open 4 done 0 failed
33125435 build (rawhide, /rpms/python-ogr.git:c298df5e540ba1d010366e102c1c75d4f5b0b0cc) completed successfully
That was rough, can't wait to do this with packit.
Let's do Fedora 30 now:
$ packit propose-update --dist-git-branch f30
INFO: Running 'anitya' versioneer
using \"f30\" dist-git branch
syncing ./python-ogr.spec
INFO: Downloading file from URL https://files.pythonhosted.org/packages/source/o/ogr/ogr-0.0.3.tar.gz
100%[=============================>] 17.95K eta 00:00:00
downloaded archive: /tmp/tmpl5xxq22x/ogr-0.0.3.tar.gz
uploading to the lookaside cache
PR created: https://src.fedoraproject.org/rpms/python-ogr/pull-request/3
And so on...
As you can see, packit is useful for us right away.
We'll be delighted if you try it out and let us know what you think.
Our sprint nears an end which means we have released a new version of packit -\n0.2.0! You can\nexpect a new release after every sprint (i.e. every 2 weeks).
The 0.2.0 version has a bunch of new features and improvements: you can find\na complete list in the\nchangelog.\nWe also have a detailed\ndocumentation\nfor all the workflows packit covers.
Let's get through what's new:
package_name → downstream_package_nameupstream_name → upstream_project_namepackit propose-update to create a pull request in Fedora dist-git with\nthe selected upstream releasepackit build to build the new upstream release once the pull request is\nmergedpackit create-update creates a new bodhi update (if you\nchose a stable Fedora release)srpm command which creates an SRPM out of the local\ncontent of your upstream repository.sync-from-downstream is the\ncommand.propose-update received numerous improvements:--local-contentfedpkg new-sources using\n--force-new-sources and bypass the caching mechanism.Please make sure you are installing 0.2.0:
$ dnf install --enablerepo=updates-testing packit
Or
$ pip3 install --user packitos
You can also install packit from master branch, if you are brave enough:
$ pip3 install --user git+https://github.com/packit-service/packit
I'd like to show you how we used packit to bring a new upstream\nrelease of ogr into Fedora, a library which packit is using.
Once we have performed an upstream release of ogr, we can propose an update in\ndist-git:
$ git clone https://github.com/packit-service/ogr && cd ogr/
$ packit propose-update
INFO: Running 'anitya' versioneer
Version in upstream registries is '0.0.3'.
Version in spec file is '0.0.3'.
Picking version of the latest release from the upstream registry over spec file.
Checking out upstream version 0.0.3
Using 'master' dist-git branch
Cloning repo: https://src.fedoraproject.org/rpms/python-ogr.git -> /tmp/tmpb9xlvdhj
Syncing /home/tt/g/user-cont/ogr/python-ogr.spec
Archive ogr-0.0.3.tar.gz found in lookaside cache (skipping upload).
ERROR Cmd('git') failed due to: exit code(1)
cmdline: git commit -s -m [packit] 0.0.3 upstream release -m Upstream tag: 0.0.3
Upstream commit: 059d21080a7849acff4626b6e0ec61830d537ac4
stdout: 'On branch 0.0.3-master-update
nothing to commit, working tree clean'
Whoops, it seems that I have messed up, I forgot to bump the spec file in the\nupstream repo when doing the release. I will bump it locally and utilize\n--local-content argument:
$ rpmdev-bumpspec -n 0.1.0 -c 'New upstream release: 0.1.0' *.spec
$ packit propose-update --local-content
INFO: Running 'anitya' versioneer
Version in upstream registries is '0.0.3'.
Version in spec file is '0.1.0'.
Picking version of the latest release from the upstream registry over spec file.
Using 'master' dist-git branch
Cloning repo: https://src.fedoraproject.org/rpms/python-ogr.git -> /tmp/tmpd9j4se27
Syncing /home/tt/g/user-cont/ogr/python-ogr.spec
Archive ogr-0.1.0.tar.gz found in lookaside cache (skipping upload).
INFO: Downloading file from URL https://files.pythonhosted.org/packages/source/o/ogr/ogr-0.1.0.tar.gz
100%[=============================>] 20.25K eta 00:00:00
Downloaded archive: '/tmp/tmpd9j4se27/ogr-0.1.0.tar.gz'
About to upload to lookaside cache
won't be doing kinit, no credentials provided
PR created: https://src.fedoraproject.org/rpms/python-ogr/pull-request/6
Once the scratch build is done and tests passed we merged and built it:
$ packit build
Using 'master' dist-git branch
Cloning repo: https://src.fedoraproject.org/rpms/python-ogr.git -> /tmp/tmprp3cmdjy
Building python-ogr-0.1.0-1.fc31 for rawhide
Created task: 33616980
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=33616980
We have done the same for F30 and F29.
The previous commands were run in the directory of the upstream repository. Packit also accepts path to your upstream clone, or even URL. So let's create a bodhi update for python-ogr by specifying the upstream repo URL:
$ cd $HOME
$ packit create-update --dist-git-branch f29 https://github.com/packit-service/ogr
Cloning repo: https://github.com/packit-service/ogr -> /tmp/tmpdkdadmn_
Koji builds for package python-ogr and koji tag f29-updates-candidate:
- python-ogr-0.1.0-1.fc29
Cloning repo: https://src.fedoraproject.org/rpms/python-ogr.git -> /tmp/tmpn1809ec9
Bodhi update FEDORA-2019-78948e62d2:
- https://bodhi.fedoraproject.org/updates/FEDORA-2019-78948e62d2
- stable_karma: 3
- unstable_karma: -3
- notes:
New upstream release: 0.1.0
And that's it, no need to access dist-git any more.
Please give packit a try and let us know what you think.
In the previous post we promised to\nprovide a new release every 2 weeks and we are already breaking this promise as\nit's been 3 weeks since then. We decided to wait with the release to merge\nseveral pull requests related to source-git support.
Now the good news. You can find a complete list of new features and\nimprovements of version\n0.3.0 in the\nchangelog.
propose-update and sync-from-downstream supports copying\ndirectories.status! It displays useful upstream/downstream info.~/.config/packit.yaml).packit status example$ packit status
Cloning repo: https://src.fedoraproject.org/rpms/packit.git -> /tmp/tmp84we_6n8
Downstream PRs: No open PRs.
f29: 0.2.0
f30: 0.2.0
master: 0.2.0
It's been over a month since we released packit \"0.3.0\". Here comes packit 0.4.0 (and patch release 0.4.1) and as always they bring a lot of new features and improvements.
You can find a complete list in the\nchangelog.
srpm command now works also with Source-git.status command now access remote APIs asynchronously in parallel, which should speed up\nthe execution.--dry-run option to not perform any remote changes (pull requests or comments).listen-to-fedmsg command.Another relase after a month since 0.4.1, this time mostly with bug fixes.
We've been busy polishing our GitHub App recently, therefore we had no resources for new features.
See CHANGELOG for more details.
/koji-builds endpoint to be more consistent with /copr-builds endpoint (packit-service#791).test job also on Pagure and GitLab thanks to that.pkg_name-v1.2.3), it is possible to use upstream_tag_template to extract version from the tag, which will be used in a subsequent task. doc packit#959--remote is global option now and available for all commands. Because of this sync-from-downstream --remote was renamed to --remote-to-push. Remote can now be specified in the user's config (via upstream_git_remote parameter). packit#977Following bugs were fixed:
%setup line in a spec file - you are now able to set content of -n option via archive_root_dir_template config option, it defaults to {upstream-pkg-name}. doc packit#834With this blog post we'd like to continue with the idea of openly communicating changes in Packit.\nSince most of the developers use Packit as the GitHub App (which uses code from this repository - Packit Service), this blog will be about changes in all the parts, i.e. the GitHub App, the Packit Service and Packit itself.
At the moment the workflow is that one of us manually triggers production container image build at the end of a week.\nThis image is then automatically deployed into our production instance of the service over a weekend (Sun/Mon night) so that everyone can start a week with all the amazing stuff we added the previous week.\nIn case an issue makes it through our staging instance into production uncaught, we can easily rollback on Monday.\nThe same person also writes down what's changed in Packit (service/app) since previous deployment.
Previous post is almost half a year old so we won't list all the changes since then, but only since last deployment, i.e. since end of December.
Previous deployment was running packit-0.7.1.\nWe haven't released a newer version since then, but in the service we install Packit from the Git repository (we have a separate stable git branch for our production deployment).\nFrom the most visible changes, Packit now:
Now:
Changes not visible to end users:
packit status (CLI) now shows also latest Copr builds. (#579)fedora-development, fedora-stable, fedora-all) can now be used in the packit config file. (#619)/packit build comment into a PR. (#290)upstream_package_name/downstream_package_name given in .packit.yaml, they now default to the name of the GitHub repo. (#624)jobs are defined in .packit.yaml packit by default runs build job on fedora-stable targets and propose_downstream on fedora-all branches. (#625)build command has nicer output. (#630)