Add workflows for OBS integration

[dirkmueller]

No description provided.

[ipetrov117]

This is definitely a step in the right direction, however I struggle to understand how this configuration alone would be enough.

This may be my lack of OBS knowledge, but shouldn't we also define here links to the other packages? Also shouldn't we enable the publish flags by default?

I tried to test this and without these two additional configurations I was not able to have all the pieces in place, where I can pull a release manifest for the currently setup project. I noticed in your testing project you had configured a link to devel:UnifiedCore:Tumbleweed on the project meta level. Is this something that we can replicate using the OBS workflows instead of having to manually write it in the meta?

Apologies, if I am missing something obvious.

[dirkmueller]

This is definitely a step in the right direction, however I struggle to understand how this configuration alone would be enough.

Never said it would be enough :)

This may be my lack of OBS knowledge, but shouldn't we also define here links to the other packages?

imho this is done via the template project.

Also shouldn't we enable the publish flags by default?

publish is enabled by default? we can set it explicitly but that wouldn't change it.

I tried to test this and without these two additional configurations I was not able to have all the pieces in place, where I can pull a release manifest for the currently setup project. I noticed in your testing project you had configured a link to devel:UnifiedCore:Tumbleweed on the project meta level. Is this something that we can replicate using the OBS workflows instead of having to manually write it in the meta?

I think so, but I haven't tested this end to end.

[ipetrov117]

imho this is done via the template project.
publish is enabled by default? we can set it explicitly but that wouldn't change it.

Might be the case, but I was not able to do this, for example I have this source_project (template).

Tweaking the suggested implementation from the PR to:

---
pr:
  steps:
  - branch_package:
      source_project: devel:UnifiedCore:Tumbleweed
      source_package: elemental
      target_project: home:ipetrov117:UC-playground:PRs
  filters:
    event: pull_request

When opening a PR I get the following happen:

1. A subproject is created with the elemental package inside of it. However this subproject is missing:
   • All the links from the template project
   • Has disabled publish by default, despite the template project having it enabled.

I am probably missing something, or not doing something correctly, but this is what I found out while trying to get this to work.

[ipetrov117]

By not having links to the elemental-base-os won't we have the release manifest point to non-existent container images? IIUC it will point to whatever is under IMG_PREFIX and that would be the branched subproject, so won't it point to something like registry.opensuse.org/<target_project>/<source_package>/pr-X/containers/<uc-base-os-kernel-default/uc-base-kernel-default-iso>? If that is the case, these containers will be missing from the subproject, as they are not linked, or am I missing something?

[ipetrov117]

It seems that we now have the correct setup to create the necessary subproject and have it populated with the correct branched/linked packages.

However, I am still not sure how a change from a PR will land onto the elemental package that this newly created subproject would have branched out. I see that we trigger the _service file of the "source" elemental package, but it refers to the upstream repo's main branch. Don't we need to change that to also point to the fork from which the PR is coming from, so that we can ensure the contents that this subproject is being built against are actually coming from the PR's fork instead of upstream's main branch?

[dirkmueller]

However, I am still not sure how a change from a PR will land onto the elemental package that this newly created subproject would have branched out. I see that we trigger the _service file of the "source" elemental package, but it refers to the upstream repo's main branch. Don't we need to change that to also point to the fork from which the PR is coming from, so that we can ensure the contents that this subproject is being built against are actually coming from the PR's fork instead of upstream's main branch?

this happens automatically as there is a _branch_project file committed which is preferred, when existing, over the main _service file. see https://build.opensuse.org/projects/devel:UnifiedCore:Tumbleweed:PRs:dirkmueller:elemental:PR-5/packages/elemental/files/_branch_request?expand=1

[davidcassany]

If I understand it correctly then we should ideally have some git workflow to actually wait for the build and trigger the integration tests to use the built binaries from the PR generated project, is that right? Meanwhile this is essentially simply validating it "builds" (quoted as the spec file is not part of the repository, hence any required change is not present in the PR so not represented in the generated project too).

LGTM, it will be helpful to actually test and iterate on more sophisticated automation.

[dirkmueller]

If I understand it correctly then we should ideally have some git workflow to actually wait for the build and trigger the integration tests to use the built binaries from the PR generated project, is that right? Meanwhile this is essentially simply validating it "builds" (quoted as the spec file is not part of the repository, hence any required change is not present in the PR so not represented in the generated project too).

Yes, my understanding is that @ipetrov117 has been working on (some parts of) that as part of #331 and I will pick up whatever is left to do if anything.

LGTM, it will be helpful to actually test and iterate on more sophisticated automation.