-
Notifications
You must be signed in to change notification settings - Fork 685
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce a Product class, make the project work with it #10529
Introduce a Product class, make the project work with it #10529
Conversation
b5adee0
to
1016902
Compare
41de622
to
e9c5b67
Compare
The object is a drop-in replacement for the dictionary, but it can save and load itself, and will be extensible easier.
Formerly, the product_yaml contents were used, which broke after it ceased to be a dictionary.
e9c5b67
to
0561307
Compare
0561307
to
655711f
Compare
|
||
import ssg.products | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the pros and cons of having this a separate script versus including this to compile_all.py?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that before the functionality is stable, having it as a fast and separate step is convenient for playing around with. I don't think that the separate step causes any problems or notable inefficiencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, :) just made a few minor comments.
As product_yaml is a required argument, don't handle the possibility of not being supplied
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the PR looks good. I did a review and it makes sense, the build process works as expected, the compiled product.yml looks sane.
Move macros that define build steps that compile source code into compiled artifacts to a separate macro.
Code Climate has analyzed commit 136d279 and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 90.9% (50% is the threshold). This pull request will bring the total coverage in the repository to 52.5% (0.1% change). View more on Code Climate. |
Fix fallout from ComplianceAsCode#10529
Description:
The project uses the concept of "product yaml" data - essentially product properties s.a. name, package manager and so on. Up until now, the format was a simple dictionary, which was enough to hold the data and to expose them later, but as products can have a lot of properties that can be
a smarter approach is needed.
See https://complianceascode.github.io/template/2023/04/25/mrac.html#go-declarative for context - the aim is to be able to define and use product properties to be able to write e.g.
{{% if product.prefers_single_file_sshd_configuration %}}
instead of{{% if product in ("rhel8", "rhel9", "ol8", ...) %}}
.Rationale:
A new class Product has been introduced, and it mimics a dictionary for the time being.
If this gets accepted, the next goal would be to introduce files that are read during the build process that allow to specify m:n product-property relationship.
As of now, this mapping is partially present in ssg/constants.py, and I am sure you will agree that source code is no place for defining what should be the default
grub2
path, and so on.Review Hints: