search

openSUSE / open-build-service

Build and distribute Linux packages from sources in an automatic, consistent and reproducible way #obs
https://openbuildservice.org
GNU General Public License v2.0
937 stars 440 forks source link

Github App for Build on PR #8703

Closed SchoolGuy closed 1 week ago

SchoolGuy commented 5 years ago

Is your feature request related to a problem? Please describe. This is not per se related to a problem. But imagine a project living on github/gitlab and maintaining everything in the git repository and using OBS to build the project. If now a contributor makes a PR the contributor would need to fork the package in an ideal world (or at least get it on his local machine and build it there) and then apply with a patch his changes on top of git head and then build the package.

Describe the solution you'd like Have a Github App like Travis or Appvoyer and see if the package would build if the PR is merged. Green Checkmark if it passes, Red Cross if not. In an ideal world I would get also the link to the build if I click on the Line. Optionally one could have a Checkmark/Cross for every arch/OS the package is built.

Describe alternatives you've considered In the project I am working with, we currently have dockerfiles which are then executed to build the package-rpms in Travis which is reporting for success as a Github Integration but I don't like that very much as Travis should in my eyes be used for testing and the buildservice for building.

Additional context This is possibly related to https://github.com/openSUSE/open-build-service/issues/2908

coolo commented 5 years ago

See https://github.com/openSUSE/openSUSE-release-tools/pull/2295 linking to https://build.opensuse.org/package/show/openSUSE:Tools:OSRT:TestGithub:PR-2295/openSUSE-release-tools

And https://github.com/openSUSE/open-build-service/pull/7557 linking to https://build.opensuse.org/package/show/OBS:Server:Unstable:TestGithub:PR-7557/obs-server

It's all happening with (forks of) https://github.com/openSUSE/obs-tools/tree/master/pull_request_package

It's not an github, but a bot using the github status API but it serves the same purpose.

SchoolGuy commented 5 years ago

That is indeed loveley. What is your desired behavior with issues like this? Close it now or when the feature is merged?

adrianschroeter commented 5 years ago

The real solution would be to do that via a token trigger. But it needs also an extension for the obs_scm service, because it needs to read from the other repo/branch....

coolo commented 5 years ago

Well, patching _service files doesn't require rocket science

dcermak commented 5 years ago

This could be maybe implemented as a Github action: I think that everything that needs to be touched to test a pull request is modifiable via the API, so the github action could do all that. You'd unfortunately need to provide it with the token that @adrianschroeter mentioned as a secret variable. And it could be inconvenient if there's a mass rebuild going on and your build is stuck for hours.

The advantage of creating a github action would be:

  1. probably no changes required on OBS' side
  2. no additional hosting required, "just create the action"[¹] and publish it to Github's store

¹: probably a lot of work actually

Conan-Kudo commented 4 years ago

One thing that I think would be very interesting is extending Packit to support OBS as a backend in addition to COPR. The work that the @packit-service team is doing would fit very well with this idea. I've spoken to @TomasTomecek at Flock last year about it, and he was definitely keen on the idea of also being able to support OBS as a backend.

It's something that's been on my radar to further evolve the Git-oriented workflow for packaging for $DAYJOB as well.

adrianschroeter commented 4 years ago

On Mittwoch, 8. Januar 2020, 01:41:30 CET Neal Gompa (ニール・ゴンパ) wrote:

One thing that I think would be very interesting is extending Packit to support OBS as a backend in addition to COPR. The work that the @packit-service team is doing would fit very well with this idea. I've spoken to @TomasTomecek at Flock last year about it, and he was definitely keen on the idea of also being able to support OBS as a backend.

It's something that's been on my radar to further evolve the Git-oriented workflow for packaging for $DAYJOB as well.

supporting branch & build when creating pull requests?

yes ....

--

Adrian Schroeter adrian@suse.de Build Infrastructure Project Manager

SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer

Conan-Kudo commented 4 years ago

@adrianschroeter Yes, Packit already does exactly this model when setting up builds for PRs in COPR. It would map perfectly to OBS.

TomasTomecek commented 4 years ago

@Conan-Kudo thanks for the headsup

Yup, in packit, we provide feedback on PRs - does the PR build in downstream? if it does, we install all the packages in a clean VM and let you know if your tests pass.

As Neal said, we build everything exclusively in Fedora COPR. I'd say that supporting OBS as a build backend sounds lovely (auth & resources would be crucial to get right, no idea how it works in OBS). Sadly we have no manpower to drive such a thing - happy to talk to someone about this.

For more info: https://packit.dev/packit-as-a-service/

perlpunk commented 4 years ago

I experimented with a GitHub Action: https://github.com/perlpunk/action-open-build-service-pr/tree/dev It's all in the dev branch so far.

perlpunk commented 4 years ago

Ok, I created a first experimental version: https://github.com/perlpunk/action-open-build-service-pr v0.0.1

If you think this could be useful, I would be glad if you try it out and see if it works. I think everything needed is in the Readme.

Here is a test run on os-autoinst: https://github.com/perlpunk/os-autoinst/runs/773334868

SchoolGuy commented 4 years ago

I would vote to make this an official openSUSE project once this is stable enough.

SchoolGuy commented 4 years ago

(If I can I will set it up for Cobbler in the near future.)

perlpunk commented 4 years ago

The thing with the Github secrets is a bit weird. It says that you need to set the secrets yourself if running in a forked project. But when doing a pull request, it wants to use the source project's secrets. I wonder if this is really safe. If I know the source project has OBS credentials stored, all I need to do is create a pull request that does some possibly evil osc commands.

So the source project should use a dedicated account that has no write access anywhere except their own home project.

SchoolGuy commented 4 years ago

Sooo we need service accounts. That is probably not so good as this would cause to have unused accounts in the openSUSE System. A more elegant solution would be if that is solved on the OBS side... Or am I wrong?

perlpunk commented 4 years ago

For openQA/os-autoinst we are currently thinking about creating a service account with a dedicated Mailing List email address. Would of course be cool if there is a possibility to make this nicer on OBS side.

perlpunk commented 4 years ago

Just a note: for pull requests, it currently does not get the correct GITHUB_SHA. See https://github.community/t/github-sha-not-the-same-as-the-triggering-commit/18286/2

Also the secrets thing is still not resolved. Still investigating :-/

hennevogel commented 1 week ago

Done in https://openbuildservice.org/help/manuals/obs-user-guide/cha-obs-scm-ci-workflow-integration

dcermak commented 1 week ago

Done in https://openbuildservice.org/help/manuals/obs-user-guide/cha-obs-scm-ci-workflow-integration

Not really, Github apps setup all the integrations automatically for you. The current setup still requires you to manually configure webhooks and everything.

hennevogel commented 1 week ago

That is in the plan for SCM/CI workflows... https://trello.com/c/5eq64S8X