Skip to content
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

roles/kvm: fix option description eval #1282

Merged
merged 1 commit into from
Feb 13, 2025

Conversation

osnyx
Copy link
Member

@osnyx osnyx commented Feb 11, 2025

literalExpression was not taken from lib and hence caused the fc-search eval to fail.

I also checked all other occurances of literalExpressions in the platform code. Almost all of them ar placed after a global with lib; which is bad style but at least causes them to eval fine.

Part of fixing the fc-search eval for 24.11. Not necessarily complete.

PL-133423

@flyingcircusio/release-managers

Release process

  • Created changelog entry using ./changelog.sh: no, cosmetic change

PR release workflow (internal)

  • PR has internal ticket
  • internal issue ID (PL-…) part of branch name
  • internal issue ID mentioned in PR description text
  • ticket is on Platform agile board
  • ticket state set to Pull request ready
  • if ticket is more urgent than within the next few days, directly contact a member of the Platform team

Design notes

  • Provide a feature toggle if the change might need to be adjusted/reverted quickly depending on context. Consider whether the default should be on or off. Example: rate limiting.
  • All customer-facing features and (NixOS) options need to be discoverable from documentation. Add or update relevant documentation such that hosted and guided customers can understand it as well.

Security implications

  • Security requirements defined? (WHERE)
    • ensure proper documentation on search.flyingcircus.io: fc-search needs to eval the 24.11 platform
  • Security requirements tested? (EVIDENCE)
    • existing automated tests still pass
    • fc-search.service displays the first occuring eval failure. This one is fixed, let's move forward one at a time.

Copy link
Member

@leona-ya leona-ya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's not really the use case for literalExpression, as this is not a parseable nix-string, but fine for me for fixing the eval.

`literalExpression` was not taken from lib and hence caused the
fc-search eval to fail.

I also checked all other occurances of `literalExpressions` in the
platform code. Almost all of them ar placed after a global `with lib;`
which is bad style but at least causes them to eval fine.

PL-133423
@osnyx osnyx force-pushed the PL-133423-literalExpression branch from 26fe0cd to 0398333 Compare February 13, 2025 11:21
@osnyx osnyx merged commit 9581e12 into fc-24.11-dev Feb 13, 2025
2 checks passed
@osnyx osnyx deleted the PL-133423-literalExpression branch February 13, 2025 17:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants