DO NOT DELETE nor CLOSE: PR base:main <- compare: sps-test-main - #4
DO NOT DELETE nor CLOSE: PR base:main <- compare: sps-test-main#4ejcsid wants to merge 73 commits into
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughGitHub Actions workflow triggers now include weekday schedules with explicit timezones. CI, CodeQL, and documentation workflows target ChangesWorkflow trigger configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/deploy-docs.yml:
- Around line 8-11: Update the workflow trigger and deployment authorization
around the production-branch restriction so pushes to sps-test-main cannot run
the Pages deployment job with pages: write or id-token: write permissions. Keep
deployment limited to main, or add an explicit environment and condition that
prevents unintended test-branch deployments.
In @.github/workflows/release-npm.yml:
- Around line 23-25: Update the scheduled workflow’s cron configuration to use
the agreed Europe/Berlin timezone instead of America/New_York, leaving the
existing cron expression unchanged.
- Around line 23-25: Update the scheduled trigger handling in the release
workflow so the release job does not run with empty app-path and release-version
inputs. Either restrict the job to workflow_dispatch runs using its condition,
or provide explicit fixed values for scheduled executions while preserving the
existing manual-input behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 5b949eed-b36b-4758-9800-6cf62829a38c
📒 Files selected for processing (10)
.github/workflows/actionlint.yml.github/workflows/build.yml.github/workflows/codeql.yml.github/workflows/dependency-review.yml.github/workflows/deploy-docs.yml.github/workflows/dockercompose-healthcheck.yml.github/workflows/pr-labeler.yml.github/workflows/release-maven.yml.github/workflows/release-npm.yml.github/workflows/trivy.yml
| - sps-test-main | ||
| paths: | ||
| - "docs/**" | ||
| - ".github/workflows/deploy-docs.yml" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not authorize Pages deployment from the test branch unintentionally.
Pushes to sps-test-main now reach a job with pages: write and id-token: write permissions, while Line 29 still states that deployment is restricted to main. Keep deployment restricted to the production branch, or add an explicit environment/condition for test-branch deployments.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/deploy-docs.yml around lines 8 - 11, Update the workflow
trigger and deployment authorization around the production-branch restriction so
pushes to sps-test-main cannot run the Pages deployment job with pages: write or
id-token: write permissions. Keep deployment limited to main, or add an explicit
environment and condition that prevents unintended test-branch deployments.
| schedule: | ||
| - cron: '30 5 * * 1-5' | ||
| timezone: "America/New_York" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
sed -n '1,120p' .github/workflows/release-npm.yml && printf '\n---\n' && rg -n "Europe/Berlin|America/New_York|timezone:" .github/workflows . -g '!**/node_modules/**' -g '!**/dist/**' -g '!**/build/**'Repository: it-at-m/sps-test
Length of output: 3988
Use the agreed schedule timezone. .github/workflows/release-npm.yml still uses America/New_York for the cron schedule; switch it to Europe/Berlin to match the other scheduled workflows.
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 4-25: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release-npm.yml around lines 23 - 25, Update the scheduled
workflow’s cron configuration to use the agreed Europe/Berlin timezone instead
of America/New_York, leaving the existing cron expression unchanged.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
sed -n '1,220p' .github/workflows/release-npm.ymlRepository: it-at-m/sps-test
Length of output: 3174
🏁 Script executed:
rg -n "Europe/Berlin|America/New_York|timezone|release-npm" .github README* docs* . 2>/dev/nullRepository: it-at-m/sps-test
Length of output: 2044
🌐 Web query:
GitHub Actions schedule timezone field supported inputs context schedule event workflow_dispatch docs
💡 Result:
GitHub Actions supports a timezone field within the schedule event trigger, allowing workflows to run based on a specified IANA timezone rather than defaulting to UTC [1][2][3]. Schedule Event Timezone Support: - You can specify a timezone using an IANA timezone string (e.g., "America/New_York") alongside your POSIX cron expression [1][2]. - This feature allows for timezone-aware scheduling, including proper handling of daylight saving time transitions [1][2]. - Example configuration: on: schedule: - cron: '30 5 * * 1-5' timezone: "America/New_York" Workflow_dispatch Contexts: - Workflows triggered by workflow_dispatch can access inputs provided during the trigger event [4][5]. - The recommended way to access these values is through the inputs context (e.g., ${{ inputs.input_name }}) [6][4][5]. - For backward compatibility, these inputs are also available within the github.event.inputs context [5]. Additional Context: - The timezone field support for scheduled workflows was introduced in March 2026 [3][7]. - The schedule event triggers workflows only if the workflow file exists on the default branch [2][8]. - Scheduled workflows may be delayed during periods of high system load [2]. - You can define up to 25 inputs for a workflow_dispatch event [8].
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 2: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
- 3: https://github.blog/changelog/2026-03-19-github-actions-late-march-2026-updates/
- 4: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 5: https://github.blog/changelog/2022-06-09-github-actions-inputs-unified-across-manual-and-reusable-workflows/
- 6: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- 7: feat: add timezone field support to on.schedule cron entries github/gh-aw#22018
- 8: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/manually-run-a-workflow?tool=webui
🏁 Script executed:
rg -n "use-pr|release-version|app-path|workflow_dispatch|schedule" .github/workflows . 2>/dev/nullRepository: it-at-m/sps-test
Length of output: 3101
🌐 Web query:
GitHub Actions schedule event inputs context empty default workflow_dispatch only docs
💡 Result:
In GitHub Actions, the inputs context and the github.event.inputs context are specifically designed for manually triggered workflows using the workflow_dispatch event [1][2][3]. When a workflow is triggered by a schedule event, it does not support the definition or receipt of inputs in the same way as workflow_dispatch [4][5]. Consequently, if a workflow is triggered by a schedule event, the inputs context will be empty [4]. Scheduled workflows are triggered automatically based on a cron schedule rather than by a user providing input values [2]. If you need to trigger a workflow both on a schedule and manually with inputs, the standard practice is to separate your logic [4][6]: 1. Create a primary workflow (or a reusable workflow using workflow_call) that contains the core logic and accepts the required inputs [6]. 2. Create a separate workflow_dispatch trigger that calls the primary workflow with specific inputs [4][6]. 3. Create a separate schedule trigger that calls the same primary workflow, passing in static or default values for the inputs [4][6].
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
- 2: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 3: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow
- 4: https://github.com/orgs/community/discussions/137750
- 5: https://stackoverflow.com/questions/72539900/schedule-trigger-github-action-workflow-with-input-parameters
- 6: https://github.com/orgs/community/discussions/74698
Guard the cron trigger or pass fixed values. .github/workflows/release-npm.yml schedules the release without defining app-path or release-version, so ${{ inputs.app-path }} and ${{ inputs.release-version }} are empty on scheduled runs while use-pr still executes. Either gate this job to workflow_dispatch or supply explicit scheduled values.
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 4-25: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release-npm.yml around lines 23 - 25, Update the scheduled
trigger handling in the release workflow so the release job does not run with
empty app-path and release-version inputs. Either restrict the job to
workflow_dispatch runs using its condition, or provide explicit fixed values for
scheduled executions while preserving the existing manual-input behavior.
|
@ejcsid also man muss dann auch den default Branch ändern, sonst funktioniert der Scheduler nicht. |
GitHub nervt. |
Anderer Button, dann geht es. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
chore(frontend): bump release version to
…nto sps-test-main
Change webex step
Co-authored-by: Silke <33521006+ejcsid@users.noreply.github.com>
chore(backend): bump release version to 0.0.4-SNAPSHOT
Workflow release-mvn doesn't support scheduling yet as it isn't able to upgrade to a newer version. This has to be implemented with it-at-m/lhm_actions#330
Fix merge conflicts
3 participants
This pull request is used to push changes from main into sps-test-main branch.
sps-test-main branch is used to run all existing workflows with scheduled triggering.
Summary by CodeRabbit