search

openSUSE / obs-docu

Official Open Build Service Documentation. Content gets reviewed and edited. Generated books are available at http://www.openbuildservice.org
34 stars 70 forks source link

user: rewrite parts of the Build Constraints chapter #323

Closed smithfarm closed 7 months ago

smithfarm commented 7 months ago

Fixes: https://github.com/openSUSE/obs-docu/issues/291

hennevogel commented 7 months ago

In general I would also mention how to get an idea what a build is using through the _statistics file that every build produces. This question comes up every time we discuss constraints.

https://build.opensuse.org/package/statistics/home:hennevogel/gifup/openSUSE_Tumbleweed/x86_64

and the API

https://api.opensuse.org/apidocs/#/Build/get_build__project_name___repository_name___architecture_name___package_name___statistics

smithfarm commented 7 months ago

In general I would also mention how to get an idea what a build is using through the _statistics file that every build produces.

Yes, the idea to fix #291 is what got me started on this, but I found that (if you'll forgive me comparing the fix to an airplane) the fix had no nice place to land. So I started building an airport...

adrianschroeter commented 7 months ago

On Freitag, 9. Februar 2024, 10:13:39 CET Nathan Cutler wrote:

@smithfarm commented on this pull request.

  • starting the bs_worker process. It can be used to run on specific hosts,
  • which may be used for running benchmarks in a reproducible way. This
  • constraint can also be defined as a negative definition using the
  • exclude=true
  • attribute. However, the hostlabel is always specific to one OBS instance.
  • You should avoid it as much as possible, since building with this constraint
  • in another instance is usually not possible. Use any of the other
  • constraints if possible.
  • Example for _constraints file:
  • <constraints exclude="false">
  • <hostlabel>benchmark_runner</hostlabel>
  • Setting constraints
  • Constraints can be set for a particular package by including a
  • _constraints file in the package.
  • Constraints can also be included directly in the build recipe (spec,
  • dsc, etc.), provided the build recipe parser supports it.

I can write expicitly that only spec and Dockerfile are supported, but then the moment support is expanded to another recipe that statement will be wrong...

yes, that is our reality that we always need to run after the documentation on implementation :)

--

Adrian Schroeter @.***> Build Infrastructure Project Manager

SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

hennevogel commented 7 months ago

yes, that is our reality that we always need to run after the documentation on implementation :)

Documentation is part of the implementation...

smithfarm commented 7 months ago

yes, that is our reality that we always need to run after the documentation on implementation :)

@adrianschroeter I understand the sentiment and that this is the current reality, but it doesn't have to be that way. I can imagine an API call /buildconstraints/supported/buildrecipeparsers which would return the real answer to the question "which recipe parsers support buildconstraints?" And then the documentation could tell folks how to get the real answer, instead of presenting a false answer.

adrianschroeter commented 7 months ago

On Freitag, 9. Februar 2024, 13:09:56 CET Nathan Cutler wrote:

yes, that is our reality that we always need to run after the documentation on implementation :)

@adrianschroeter I understand the sentiment and that this is the current reality, but it doesn't have to be that way. I can imagine an API call /buildconstraints/supported/buildrecipeparsers which would return the real answer to the question "which recipe parsers support buildconstraints?" And then the documentation could tell folks how to get the real answer, instead of presenting a false answer.

This is not an api feature, but a build process tooling support task.

And even when you have that, you would still need to document the specific syntax for each build description format.

--

Adrian Schroeter @.***> Build Infrastructure Project Manager

SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

smithfarm commented 7 months ago

OK, this discussion has helped me and I now know how to deal with this "supported build recipes" problem. Wait for it ;-)

smithfarm commented 7 months ago

will open a clean PR