Skip to content

Bump actions/checkout from 4 to 5 - #2

Closed
dependabot[bot] wants to merge 2 commits into
mainfrom
dependabot/github_actions/actions/checkout-5
Closed

dependabot[bot] wants to merge 2 commits into
mainfrom
dependabot/github_actions/actions/checkout-5

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 8, 2025

Copy link
Copy Markdown
Contributor

Bumps actions/checkout from 4 to 5.

Release notes

Sourced from actions/checkout's releases.

v5.0.0

What's Changed

⚠️ Minimum Compatible Runner Version

v2.327.1
Release Notes

Make sure your runner is updated to this version or newer to use this release.

Full Changelog: actions/checkout@v4...v5.0.0

v4.3.0

What's Changed

New Contributors

Full Changelog: actions/checkout@v4...v4.3.0

v4.2.2

What's Changed

Full Changelog: actions/checkout@v4.2.1...v4.2.2

v4.2.1

What's Changed

New Contributors

Full Changelog: actions/checkout@v4.2.0...v4.2.1

... (truncated)

Changelog

Sourced from actions/checkout's changelog.

Changelog

V5.0.0

V4.3.0

v4.2.2

v4.2.1

v4.2.0

v4.1.7

v4.1.6

v4.1.5

v4.1.4

v4.1.3

... (truncated)

Commits

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

org-config-management Bot and others added 2 commits September 8, 2025 14:10
Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 5.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v4...v5)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-version: '5'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code labels Sep 8, 2025
@larsks larsks closed this Sep 8, 2025
@dependabot @github

dependabot Bot commented on behalf of github Sep 8, 2025

Copy link
Copy Markdown
Contributor Author

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

@dependabot
dependabot Bot deleted the dependabot/github_actions/actions/checkout-5 branch September 8, 2025 14:41
akshaynadkarni added a commit to akshaynadkarni/enhancement-proposals that referenced this pull request Apr 20, 2026
Clarify in API Extensions and Design Decision osac-project#2 that freeform tier
names are the current approach for this proposal. A future proposal
addressing tier discovery and StorageClass lifecycle management may
introduce validation against the external system that owns the source
of truth for valid tier names.

Assisted-by: Cursor/Claude
akshaynadkarni added a commit to akshaynadkarni/enhancement-proposals that referenced this pull request Apr 22, 2026
Clarify in API Extensions and Design Decision osac-project#2 that freeform tier
names are the current approach for this proposal. A future proposal
addressing tier discovery and StorageClass lifecycle management may
introduce validation against the external system that owns the source
of truth for valid tier names.

Assisted-by: Cursor/Claude
akshaynadkarni added a commit to akshaynadkarni/enhancement-proposals that referenced this pull request Apr 24, 2026
Remove statements that "no tier name is special" since OSAC-shipped
templates depend on the tier name "default". Update the Proposal intro,
API Extensions, and Design Decisions osac-project#1 and osac-project#2 to consistently reflect
this. Add Design Decision osac-project#6 documenting the requirement for a shared
StorageClass with tenant: Default, storage-tier: default on every VMaaS
cluster, with rationale distinguishing the operational convention from
controller-level enforcement.

Assisted-by: Cursor/Claude
akshaynadkarni added a commit that referenced this pull request Apr 24, 2026
#32)

* MGMT-23404: add enhancement proposal for tenant storage tiers

Proposes extending the tenant-specific StorageClass mechanism to support
multiple storage tiers per tenant. Adds an optional
osac.openshift.io/storage-tier label to StorageClasses and evolves
tenant.status.storageClass (string) to tenant.status.storageClasses (list)
so the Tenant controller can resolve all available tiers per tenant.

The proposal focuses on the infrastructure layer (labeling, resolution,
selection) and describes three consumption strategies (template-driven,
user-facing DiskSpec, hybrid) without prescribing one. The initial
implementation targets Strategy A (template-driven).

Assisted-by: Cursor/Claude
Made-with: Cursor

* MGMT-23404: trim graduation criteria to N/A

OSAC has not been released; graduation milestones are not applicable yet.

Assisted-by: Cursor/Claude
Made-with: Cursor

* MGMT-23404: address CodeRabbit review feedback

- Fix contradictory wording: status.storageClass is "retained for
  backward compatibility" (not "replaced") with the new storageClasses
  list as the additive canonical representation.
- Unify storage-tier value constraint: use "lowercase Kubernetes label
  value" consistently instead of "lowercase alphanumeric" (which
  conflicts with the later paragraph allowing dashes/dots/underscores).
- Expand "no Default tier" condition to cover both explicitly labeled
  storage-tier: Default and unlabeled StorageClasses.

Assisted-by: Cursor/Claude
Made-with: Cursor

* MGMT-23404: incorporate review feedback on storage tiers proposal

- Make osac.openshift.io/storage-tier label required on all StorageClasses.
  Controller ignores StorageClasses missing the label.
- Remove the capitalized "Default" sentinel for tiers. Tier names are
  freeform lowercase values; CSPs use "default" by convention.
- Remove status.storageClass (singular) entirely instead of deprecating it.
  status.storageClasses (list) is the only field.
- Require tenant_storage_class_storage_tier parameter in Ansible role with
  no default. Role fails with descriptive error listing available tiers.
- Clarify resolution algorithm scoping: only tenant-specific and
  tenant=Default StorageClasses are considered (no tier leakage).
- Add explicit behavior for all-tiers-fail case: Tenant stays Progressing,
  StorageClassReady=False with failure details.
- Resolve all open questions: no required default tier (at least one tier
  sufficient), freeform tier names, Strategy A (template-driven) only.
- Add Design Decisions section capturing resolved questions with rationale.
- Add Migration Path section with step-by-step upgrade guidance.
- Add upgrade scenario to test plan.
- Document rejected alternatives (optional label, deprecated field).

Assisted-by: Cursor/Claude

* MGMT-23404: make lowercase constraint explicit in tier validation prose

The label table already stated tier values must be lowercase, but the
detailed validation paragraph omitted that constraint. This adds
"lowercase" to the prose so both descriptions are consistent.

Assisted-by: Cursor/Claude

* MGMT-23404: address CodeRabbit documentation nitpicks

Clarify that tenant-axis fallback applies independently per tier while
storage-tier axis has no inter-tier fallback. Update the label table
header to "Behavior when absent" with "StorageClass ignored" values.
Add kubebuilder validation markers to the ResolvedStorageClass struct.
Harden the migration script to skip already-labeled StorageClasses and
echo progress.

Assisted-by: Cursor/Claude

* MGMT-23404: add assumptions and tenant readiness criteria

Add Assumptions section documenting that external systems maintain the
source of truth for valid storage tier names and are responsible for
creating and maintaining Tenant StorageClasses. Automation for tier
discovery and StorageClass lifecycle will be addressed in a subsequent
proposal.

Expand StorageClassReady condition to explicitly state that a Tenant
cannot reach Ready without at least one StorageClass carrying both
required labels. Document the decision to use status reflection rather
than admission webhooks for validation, since StorageClass is not an
OSAC-owned resource type.

Assisted-by: Cursor/Claude

* MGMT-23404: note freeform tier names are temporary

Clarify in API Extensions and Design Decision #2 that freeform tier
names are the current approach for this proposal. A future proposal
addressing tier discovery and StorageClass lifecycle management may
introduce validation against the external system that owns the source
of truth for valid tier names.

Assisted-by: Cursor/Claude

* MGMT-23404: address Michael's review comments (1, 3, 4)

Update tracking-link to MGMT-23669 and last-updated date to 2026-04-20.

Rename ResolvedStorageClass fields from storageClassName/storageTier to
name/tier per K8s API conventions for named subobjects. The parent
storageClasses list already provides the "storage class" context, making
the prefixes redundant.

Replace "downstream consumers" with "consumers" to avoid directional
ambiguity.

Assisted-by: Cursor/Claude

* MGMT-23404: clarify StorageClass resolution goal

Reword the goal to explain why resolution is centralized: so that
osac-operator and osac-aap do not each implement the same fallback,
duplicate detection, and per-tier grouping logic. Consumers use
status.storageClasses to determine which StorageClass to use.

Assisted-by: Cursor/Claude

* MGMT-23404: inject resolved storageClasses via extra_vars

Update the proposal so that the CI controller injects the resolved
storageClasses list into the Ansible job extra_vars at trigger time,
instead of having the Ansible role query the K8s API for the Tenant CR.

The CI controller already fetches the Tenant to verify readiness before
triggering. Reading status.storageClasses at that point and passing it
through eliminates an uncached K8s API call from Ansible while keeping
the resolution logic centralized in the Tenant controller.

Assisted-by: Cursor/Claude

* MGMT-23404: correct template persona model and add default tier convention

Templates are Ansible roles written by OSAC contributors and customized
by CSPs, not created by Tenant Admins. Update user stories, personas,
and workflows to reflect this.

OSAC-shipped templates use the conventional tier name "default" so they
work out of the box on any deployment. Every VMaaS cluster must have a
shared StorageClass with tenant: Default, storage-tier: default as the
baseline. CSPs can override per-tenant and customize templates for
specialized tiers like "fast".

Remove Strategy A/B/C labels in favor of direct descriptions.

Assisted-by: Cursor/Claude

* MGMT-23404: update last-updated date to 2026-04-22

Assisted-by: Cursor/Claude

* MGMT-23404: surface default tier convention in assumptions and API sections

Mention the default tier requirement for OSAC-shipped templates in the
Assumptions section, Proposal intro, and API Extensions section so
readers encounter it early rather than only in the template convention
subsection.

Assisted-by: Cursor/Claude

* MGMT-23404: make default tier convention consistent throughout proposal

Remove statements that "no tier name is special" since OSAC-shipped
templates depend on the tier name "default". Update the Proposal intro,
API Extensions, and Design Decisions #1 and #2 to consistently reflect
this. Add Design Decision #6 documenting the requirement for a shared
StorageClass with tenant: Default, storage-tier: default on every VMaaS
cluster, with rationale distinguishing the operational convention from
controller-level enforcement.

Assisted-by: Cursor/Claude

* MGMT-23404: decouple default tier requirement from tenant: Default

The requirement for OSAC-shipped templates is that a `default` tier
resolves for every tenant, not that a shared StorageClass with
tenant: Default specifically exists. CSPs can provide this tier either
through tenant-specific StorageClasses or through a shared Default
StorageClass. Update Assumptions, Proposal intro, API Extensions,
template convention, and Design Decisions #5 and #6 to reflect this.

Also replace "magic" with "special" or "implicit" throughout.

Assisted-by: Cursor/Claude
danmanor added a commit to danmanor/enhancement-proposals that referenced this pull request Jul 12, 2026
PRD functional requirements should describe user-observable outcomes,
not internal mechanisms. Addresses EP review feedback (Important osac-project#2).

Unified PRD: removed fabric manager, K8s manager, dispatcher,
ConfigMap, Ansible role, NetworkClass, DNAT/SNAT, proto field names
from goals, user stories, and acceptance criteria.

BMaaS PRD: FR-8 rewritten to describe outcome (connectivity
established, server receives IP) instead of mechanism (switch port
configuration, network fabric). FR-11 removes "static configuration
string". FR-13 removes "network segment" internals.

CaaS PRD: FR-10 removes "first interface with role fabric". Goals
and acceptance criteria use "system determines" instead of naming
the resolution mechanism.

VMaaS PRD: FR-1 removes DNAT/SNAT parentheticals. FR-6 removes
"underlying virtualization platform". Cloud Infra Admin story
removes "(by deploying a K8s manager)".

Default PRD: removed proto field names, enum values, label names,
finalizer details, OSAC ticket references from all FRs and
acceptance criteria.

Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Dan Manor <dmanor@redhat.com>
danmanor added a commit to danmanor/enhancement-proposals that referenced this pull request Jul 26, 2026
PRD functional requirements should describe user-observable outcomes,
not internal mechanisms. Addresses EP review feedback (Important osac-project#2).

Unified PRD: removed fabric manager, K8s manager, dispatcher,
ConfigMap, Ansible role, NetworkClass, DNAT/SNAT, proto field names
from goals, user stories, and acceptance criteria.

BMaaS PRD: FR-8 rewritten to describe outcome (connectivity
established, server receives IP) instead of mechanism (switch port
configuration, network fabric). FR-11 removes "static configuration
string". FR-13 removes "network segment" internals.

CaaS PRD: FR-10 removes "first interface with role fabric". Goals
and acceptance criteria use "system determines" instead of naming
the resolution mechanism.

VMaaS PRD: FR-1 removes DNAT/SNAT parentheticals. FR-6 removes
"underlying virtualization platform". Cloud Infra Admin story
removes "(by deploying a K8s manager)".

Default PRD: removed proto field names, enum values, label names,
finalizer details, OSAC ticket references from all FRs and
acceptance criteria.

Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Dan Manor <dmanor@redhat.com>
masayag pushed a commit to masayag/enhancement-proposals that referenced this pull request Jul 27, 2026
PRD functional requirements should describe user-observable outcomes,
not internal mechanisms. Addresses EP review feedback (Important osac-project#2).

Unified PRD: removed fabric manager, K8s manager, dispatcher,
ConfigMap, Ansible role, NetworkClass, DNAT/SNAT, proto field names
from goals, user stories, and acceptance criteria.

BMaaS PRD: FR-8 rewritten to describe outcome (connectivity
established, server receives IP) instead of mechanism (switch port
configuration, network fabric). FR-11 removes "static configuration
string". FR-13 removes "network segment" internals.

CaaS PRD: FR-10 removes "first interface with role fabric". Goals
and acceptance criteria use "system determines" instead of naming
the resolution mechanism.

VMaaS PRD: FR-1 removes DNAT/SNAT parentheticals. FR-6 removes
"underlying virtualization platform". Cloud Infra Admin story
removes "(by deploying a K8s manager)".

Default PRD: removed proto field names, enum values, label names,
finalizer details, OSAC ticket references from all FRs and
acceptance criteria.

Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Dan Manor <dmanor@redhat.com>
empovit pushed a commit to empovit/osac-enhancement-proposals that referenced this pull request Aug 2, 2026
PRD functional requirements should describe user-observable outcomes,
not internal mechanisms. Addresses EP review feedback (Important osac-project#2).

Unified PRD: removed fabric manager, K8s manager, dispatcher,
ConfigMap, Ansible role, NetworkClass, DNAT/SNAT, proto field names
from goals, user stories, and acceptance criteria.

BMaaS PRD: FR-8 rewritten to describe outcome (connectivity
established, server receives IP) instead of mechanism (switch port
configuration, network fabric). FR-11 removes "static configuration
string". FR-13 removes "network segment" internals.

CaaS PRD: FR-10 removes "first interface with role fabric". Goals
and acceptance criteria use "system determines" instead of naming
the resolution mechanism.

VMaaS PRD: FR-1 removes DNAT/SNAT parentheticals. FR-6 removes
"underlying virtualization platform". Cloud Infra Admin story
removes "(by deploying a K8s manager)".

Default PRD: removed proto field names, enum values, label names,
finalizer details, OSAC ticket references from all FRs and
acceptance criteria.

Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Dan Manor <dmanor@redhat.com>
vladikr added a commit to vladikr/osac-enhancement-proposals that referenced this pull request Aug 12, 2026
Add Alternative osac-project#2: ServerCluster as top-level peer of VirtualNetwork
(uniform isolation model). Documents pros (atomic resize, simpler for
uniform deployments), cons (couples fabric lifecycles, non-uniform
membership needs multiple objects anyway), and why FabricDomain was
chosen (handles both uniform and non-uniform cases; type:multi planned
for Phase 2/3 uniform deployments).

Renumber remaining alternatives (3-5).

Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Vladik Romanovsky <vromanso@redhat.com>
tzvatot added a commit to tzvatot/enhancement-proposals that referenced this pull request Aug 13, 2026
Rewrite problem statement osac-project#2 to clearly explain why the current
generic google.protobuf.Value model cannot distinguish between
field types (InstanceTypeReference vs plain string).

Assisted-by: Claude Code <noreply@anthropic.com>

Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: Elad Tabak <etabak@redhat.com>
omer-vishlitzky added a commit that referenced this pull request Aug 18, 2026
…n, observability detail

- Reorder sequence diagram: publish to Kafka before returning inference
  response, eliminating the data-loss window (CodeRabbit inline comment)
- Add CAP-13 mechanism justification for Kafka-to-Kafka latency budget
  (AI Design Review Important #2)
- Restore observability detail in tenant attribution: structured log
  fields, alert threshold (>0 for 5m), security constraint (no full
  payloads in logs), forensic recovery path via raw topic retention
  (AI Design Review Important #1)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
htayrie-rh pushed a commit to htayrie-rh/enhancement-proposals that referenced this pull request Aug 27, 2026
Close Open Question osac-project#2: Enclave profiles drive service enablement values
via value-map extension (OSAC-4106). The Enclave plugin translates its
osacProfilesList into individual services.*.enabled flags via --set,
rather than templating entire value files.

Clarifies reconciliation with PR #380 (global.profilesList): this
design's per-service booleans are the canonical chart interface —
simpler to validate, propagate uniformly to all components, and
directly settable via Enclave value-map extension.

Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Haim Tayrie <htayrie@htayrie-thinkpadt14gen5.raanaii.csb>
empovit pushed a commit to empovit/osac-enhancement-proposals that referenced this pull request Aug 31, 2026
…n, observability detail

- Reorder sequence diagram: publish to Kafka before returning inference
  response, eliminating the data-loss window (CodeRabbit inline comment)
- Add CAP-13 mechanism justification for Kafka-to-Kafka latency budget
  (AI Design Review Important osac-project#2)
- Restore observability detail in tenant attribution: structured log
  fields, alert threshold (>0 for 5m), security constraint (no full
  payloads in logs), forensic recovery path via raw topic retention
  (AI Design Review Important osac-project#1)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
empovit pushed a commit to empovit/osac-enhancement-proposals that referenced this pull request Aug 31, 2026
Add Alternative osac-project#2: ServerCluster as top-level peer of VirtualNetwork
(uniform isolation model). Documents pros (atomic resize, simpler for
uniform deployments), cons (couples fabric lifecycles, non-uniform
membership needs multiple objects anyway), and why FabricDomain was
chosen (handles both uniform and non-uniform cases; type:multi planned
for Phase 2/3 uniform deployments).

Renumber remaining alternatives (3-5).

Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Vladik Romanovsky <vromanso@redhat.com>
empovit pushed a commit to empovit/osac-enhancement-proposals that referenced this pull request Aug 31, 2026
Close Open Question osac-project#2: Enclave profiles drive service enablement values
via value-map extension (OSAC-4106). The Enclave plugin translates its
osacProfilesList into individual services.*.enabled flags via --set,
rather than templating entire value files.

Clarifies reconciliation with PR #380 (global.profilesList): this
design's per-service booleans are the canonical chart interface —
simpler to validate, propagate uniformly to all components, and
directly settable via Enclave value-map extension.

Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Haim Tayrie <htayrie@htayrie-thinkpadt14gen5.raanaii.csb>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant