7:58 a.m.
I maintain a suite of ham radio related packages. The developer is very
active and often creates test versions adding and incrementing the "tweak"
part of the version which is removed for the full releases and the patch
level incremented.
Currently I'm just trying to keep up with them by hand using pagure forks
of the official repos so I don't accidentally pollute SCM with the changes
and build them in COPR.
Things I need to manage automagically:
1. Monitor the test URLs to look for new versions.
I could write a bash script for this and add a cron or systemd timer but I
was hoping for something that took less time as I don't have a lot of that
:)
Would it be permissible to create a <package>-testing entry in
release-monitoring.org?
2. Trigger a "fedpkg clone" and add a tweak version.
This could probably be managed with macros easy enough, %{?tweak}, or
something like that. And then use a script to substitute into "%global
tweak ..."
3. I need to download the files from a different location.
%if %{?tweak}
... use difference Source0?
4. Build the packages in COPR.
Easy enough using a bash script but is there a better way?
Thanks,
Richard
8:40 a.m.
Hi,
On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote:
4. Build the packages in COPR.
Easy enough using a bash script but is there a better way?
packit allows to create test builds in COPR based on GitHub PRs and
probably also releases. Maybe this can make it easier for you, too:
https://packit.dev/
Cheers
Till
11:17 a.m.
On Thu, Dec 31, 2020 at 8:41 AM Till Maas <opensource(a)till.name> wrote:
Hi,
On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote:
> 4. Build the packages in COPR.
>
> Easy enough using a bash script but is there a better way?
packit allows to create test builds in COPR based on GitHub PRs and
probably also releases. Maybe this can make it easier for you, too:
https://packit.dev/
I only looked at it briefly but upstream does not use github so I'm not
sure this would work. Thanks for the tip though.
Thanks,
Richard
5:21 a.m.
On Thu, Dec 31, 2020 at 3:46 PM Till Maas <opensource(a)till.name> wrote:
Hi,
On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote:
> 4. Build the packages in COPR.
>
> Easy enough using a bash script but is there a better way?
packit allows to create test builds in COPR based on GitHub PRs and
probably also releases. Maybe this can make it easier for you, too:
https://packit.dev/
Cheers
Till
You could host the repositories on GitHub (or GitLab) and get the
benefits of packit: builds in copr, results in pull requests and tests
via testing farm [1].
Though we don't have a way in packit to automatically pull upstream
content into your (downstream) git repos, yet. Having this set up with
upstream release monitoring would be interesting, or alternatively,
you could set up a github action [2] or gitlab job [3] to pull
upstream content periodically.
I can help you out to set this up if needed.
[1] https://packit.dev/docs/testing-farm/
[2]
https://docs.github.com/en/free-pro-team@latest/actions/reference/events-...
[3] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
Tomas
12:27 p.m.
On Thu, 31 Dec 2020 at 14:59, Richard Shaw <hobbes1069(a)gmail.com> wrote:
I maintain a suite of ham radio related packages. The developer is very active and often
creates test versions adding and incrementing the "tweak" part of the version
which is removed for the full releases and the patch level incremented.
Currently I'm just trying to keep up with them by hand using pagure forks of the
official repos so I don't accidentally pollute SCM with the changes and build them in
COPR.
Things I need to manage automagically:
1. Monitor the test URLs to look for new versions.
I could write a bash script for this and add a cron or systemd timer but I was hoping for
something that took less time as I don't have a lot of that :)
Would it be permissible to create a <package>-testing entry in
release-monitoring.org?
2. Trigger a "fedpkg clone" and add a tweak version.
This could probably be managed with macros easy enough, %{?tweak}, or something like
that. And then use a script to substitute into "%global tweak ..."
3. I need to download the files from a different location.
%if %{?tweak}
... use difference Source0?
4. Build the packages in COPR.
Easy enough using a bash script but is there a better way?
There would be a very neat way if "Enable Spec File preprocessing"
change was accepted but it looks like it won't happen. There are still
some options but they require keeping a spec file (template) outside
of Fedora DistGit (which should normally be the source for the spec
file). Actually, also rpkg-3 would be needed in Copr (currently rpkg-2
is there). So with rpkg-3, you could:
- have the spec file template e.g. in Pagure
- configure rpkg SCM method by using https URL of the spec file in
pagure and clone url of upstream (this is a thing currently
unsupported by rpkg-2)
- either ask the upstream developer to configure a webhook for you to
trigger a build in COPR upon a new commit or tag or configure
release-monitoring for that
With the aforementioned Fedora change, you could have just a single
spec file in Fedora DistGit and use it for official Fedora builds as
well as for upstream builds. But without that change, it is not
possible so you would need to take rendered spec files from the
template and load them into DistGit with an upstream version that you
would like to release into Fedora. That breaks Fedora DisGit
canonicity but it's the best way and many people do it anyway.
You can actually implement this workflow even today without rpkg-3 in
COPR by using COPR's custom srpm build method. There you could specify
a snippet which installs rpkg-3 into the chroot and then invokes
`rpkg` command on the spec in the pagure (again specified as https
URL) while operating on the upstream cloned repo. Of course, you could
also avoid using rpkg-3 and do something more manual on your own
(e.g. invoking git archive and sedding your spec file with the
produced sourcename).
Well, I probably didn't help you much
Anyway, best regards
clime
>
> Thanks,
> Richard
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
7:49 a.m.
It's still manually initiated, but I wrote a bash script which takes care
of the process nicely.
I just pass the package name and the test version and then:
1. It clones the package in a temporary directory
2. Used sed to change the alpha macro from 0 to 1 which I use to control
the Source URL
3. Runs "rpmdev-bumpspec -n <version>"
4. Runs "spectool -g <spec>"
5. Runs "rpkg build <COPR Project>
Thanks,
Richard
4:23 a.m.
On Saturday, January 2, 2021 2:49:21 PM CET Richard Shaw wrote:
It's still manually initiated, but I wrote a bash script which
takes care
of the process nicely.
I just pass the package name and the test version and then:
1. It clones the package in a temporary directory
2. Used sed to change the alpha macro from 0 to 1 which I use to control
the Source URL
3. Runs "rpmdev-bumpspec -n <version>"
4. Runs "spectool -g <spec>"
5. Runs "rpkg build <COPR Project>
If this manual bash script works perhaps the "custom method" [1] would
work for you 1:1. I don't know what scm provider is the upstream using so
I can not advice how to "automatically" trigger the builds in Copr using
the existing webhooks. Otherwise there's no "polling" mechanism
implemented in Copr now.
In the worst case there's 'copr build-package <project> --name
<package>' which
can be triggered daily.
[1] https://docs.pagure.org/copr.copr/custom_source_method.html
Pavel
8 a.m.
Hello Richard,
we're currently evaluating a proper approach with the Packit team, to
deduplicate (and optimize) the work, as I've written a set of tools
for such automation:
https://github.com/pvalena/theprototype
https://www.youtube.com/watch?v=gUjwSj6iypw&ab_channel=DevConf
Currently does not have wide adoption, and some tools are still
domain-specific (rubygems). So it's in the "testing" phase (please, do
file issues if you find something does not work!). After some
iterations (~months), it should be quite suitable for automating
various packaging tasks.
Should I keep you in the loop?
Regards,
Pavel
On Thu, Dec 31, 2020 at 2:58 PM Richard Shaw <hobbes1069(a)gmail.com> wrote:
I maintain a suite of ham radio related packages. The developer is very active and often
creates test versions adding and incrementing the "tweak" part of the version
which is removed for the full releases and the patch level incremented.
Currently I'm just trying to keep up with them by hand using pagure forks of the
official repos so I don't accidentally pollute SCM with the changes and build them in
COPR.
Things I need to manage automagically:
1. Monitor the test URLs to look for new versions.
I could write a bash script for this and add a cron or systemd timer but I was hoping for
something that took less time as I don't have a lot of that :)
Would it be permissible to create a <package>-testing entry in
release-monitoring.org?
2. Trigger a "fedpkg clone" and add a tweak version.
This could probably be managed with macros easy enough, %{?tweak}, or something like
that. And then use a script to substitute into "%global tweak ..."
3. I need to download the files from a different location.
%if %{?tweak}
... use difference Source0?
4. Build the packages in COPR.
Easy enough using a bash script but is there a better way?
Thanks,
Richard
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
1002
days inactive
1212
days old
7 comments
6 participants
participants (6)
-
clime -
Pavel Raiskup -
Pavel Valena -
Richard Shaw -
Till Maas -
Tomas Tomecek