Rust use-case - Githubissues

ignatenkobrain commented 5 years ago

We heavily rely on release-monitoring.org to get information about updates for rust crates. Then it is about cloning repo, running rust2rpm and check few things. Mostly this is automated. It would be great if automation would run rust2rpm and send PR automatically when new version is detected.

TomasTomecek commented 5 years ago

I'd say this is one of our long-term plans.

TomasTomecek commented 5 years ago

BTW what do you do with changelogs? How do you merge the generated spec with the one in Fedora?

ignatenkobrain commented 5 years ago

Right now we do it manually. Hopefully in future, there won't be a %changelog section at all so problem won't exist.

ignatenkobrain commented 5 years ago

But in theory, i can write some code for merging changelog.

TomasTomecek commented 5 years ago

We're planning on checking out rpkg-util to see what clime implemented wrt changelogs. @lachmanfrantisek is suppose to research it in this sprint.

hroncok commented 5 years ago

But in theory, i can write some code for merging changelog.

See https://github.com/fedora-python/rpm-changelog-merge-driver/wiki for some links.

ignatenkobrain commented 5 years ago

See https://github.com/fedora-python/rpm-changelog-merge-driver/wiki for some links.

You can't really write git merge driver because you need to change version in order to merge it. And the date.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

dhodovsk commented 4 years ago

Please see whether packit actions can solve the issue: doc: https://packit.dev/docs/actions/ - specifically post-upstream-clone and create-archive.

ignatenkobrain commented 4 years ago

@dhodovsk this won't solve the issue at all. Please read the ticket description and reopen it.

lachmanfrantisek commented 4 years ago

@ignatenkobrain thanks for the update!

This issue covers two things:

The automatic generation of specfiles using some tools like rust2rpm -- that was solved.
The automatic PRs in distgit on upstream-release:
- It works via propose_downstream job (see the relevant part of docs)
- Your problem is probably a bit different -- you cannot/don't want to install our GitHub app on the upstream repo, am I right?

ignatenkobrain commented 4 years ago

Of course nobody in sane mind is going to install GitHub app on thousands of repositories, where even some of them are hosted on gitlab or pijul! And even some projects have multiple subcrates in a repo.

The automatic generation of specfiles using some tools like rust2rpm -- that was solved.

Can you point me to a documentation about that?

ignatenkobrain commented 4 years ago

The workflow here should be when crates.io releases a new version, the spec should be generated and PR sent (keeping any non-applied-in-upstream patches). When on crates.io some version gets yanked - the PR to downgrade package should be sent.

lachmanfrantisek commented 4 years ago

Can you point me to a documentation about that?

As Dominika wrote, you can use post-upstream-clone "action" to generate your spec-file. (https://packit.dev/docs/actions)

Of course nobody in sane mind is going to install GitHub app on thousands of repositories,

By now, you can run the packit CLI from distgit.
Our current approach (and authentication) is tight to the GitHub-app.
- Not sure about the future, but currently, it will be hard for us to support projects that do not install the app.
- For this workflow, upstream-release-monitoring is probably a better fit. @Zlopez even wanted to use our code for creating distgit PRs instead of the Bugzilla's.
- As I am thinking about it, we can maybe listen on fedmsg/fedora-messaging for the new-release and trigger the "propose-update" from the distgit repo, where you can have the packit config with the post-upstream-clone action that will generate the spec...

ignatenkobrain commented 4 years ago

By now, you can run the packit CLI from distgit.

Yeah, I already can run rust2rpm which will do the same, so what's the point?

As I am thinking about it, we can maybe listen on fedmsg/fedora-messaging for the new-release and trigger the "propose-update" from the distgit repo, where you can have the packit config with the post-upstream-clone action that will generate the spec...

It would be great if I would not have to push the same config into all thousand of dist-git repos because it is painful to manage. If at some point, I decide to change something in it, I would have to change it in thousand places. This does not scale.

lachmanfrantisek commented 4 years ago

Yeah, I already can run rust2rpm which will do the same, so what's the point?

I agree that the main benefit is the CI. But there are some small benefits:

You have only one command to run.
You can run packit propose-update https://src.fedoraproject.org/rpms/my-rust-package and it will clone the repo, create SRPM, send it to lookaside cache and create the distgit PR with the changes for you. (Local run is possible as well.)

ignatenkobrain commented 4 years ago

It won't be one command to run anyway, since I'll need to inspect licenses, patch dependencies and such.

Also, from where would it download sources? What will happen to existing patches & changelog?

lachmanfrantisek commented 4 years ago

It would be great if I would not have to push the same config into all thousand of dist-git repos because it is painful to manage. If at some point, I decide to change something in it, I would have to change it in thousand places. This does not scale.

We are trying to simplify the config as much as possible. In the most optimistic scenario, you can have it empty and we would like to make the no-config scenario possible.
I agree that it does not scale.
Let's reopen and move this to the packit-service repo as an EPIC.

lachmanfrantisek commented 4 years ago

It won't be one command to run anyway, since I'll need to inspect licenses, patch dependencies and such.

OK, but the spec-changes can be reviewed in the PR.

Also, from where would it download sources?

It will get it from the specfile. So, probably crates.io?

What will happen to existing patches & changelog?

If you autogenerate the specfile, you probably don't have the patches.

If yes, you can use the source-git mechanism to have them somewhere in the form of git commits. Here is currently a problem that you don't want to maintain a thousand source-git repos. We are working on the automation of the source-git workflow (because of the centos-stream).

I probably need to look closer to some rust package to understand it better.

ignatenkobrain commented 4 years ago

Stop by #fedora-rust channel on freenode and one of rust-sig members can describe how we maintain that stuff and how it works.

lachmanfrantisek commented 3 years ago

This fits to our current source-git initiative. I am going to close this issue in favour of this Source-git SIG issue: https://pagure.io/fedora-source-git/sig/issue/16

packit / packit-service

Rust use-case #436