-
Notifications
You must be signed in to change notification settings - Fork 98
fix: Fix deployment trigger #7306
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
Conversation
Warning Rate limit exceeded@ausias-armesto has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 19 minutes and 38 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
📝 Walkthrough""" WalkthroughThe deploy workflow in the GitHub Actions configuration was updated to change its trigger conditions, making them more specific regarding package name and PR label checks. Additionally, the deployment trigger method was changed from using the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
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.
Pull Request Overview
This PR adjusts the deployment trigger logic and updates the authentication token for the repository dispatch step.
- Refines the
if
condition to only trigger on thehoprd
package when thedeploy_nodes
label is present and continuous deployment is enabled. - Switches the token used for the dispatch action from
GITHUB_TOKEN
toGH_RUNNER_TOKEN
.
Comments suppressed due to low confidence (2)
.github/workflows/build-docker.yaml:148
- The contains check includes spaces around 'deploy_nodes', which may not match the actual label. Consider using contains(steps.pr-labels.outputs.labels, 'deploy_nodes') without extra whitespace.
if: vars.CONTINUOUS_DEPLOYMENT_ENABLED == 'true' && ${{ inputs.package }} == 'hoprd' && contains(steps.pr-labels.outputs.labels, ' deploy_nodes ')
.github/workflows/build-docker.yaml:151
- [nitpick] Ensure the GH_RUNNER_TOKEN secret is defined in repository settings and scoped with minimal required permissions. Alternatively, consider granting the GITHUB_TOKEN repository_dispatch write permission to avoid managing a separate secret.
token: ${{ secrets.GH_RUNNER_TOKEN }}
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.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
-
.github/workflows/build-docker.yaml
(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:07:29.649Z
Learning: In GitHub Actions reusable workflows, the github.event_name context may inherit from the parent workflow rather than being set to 'workflow_call', allowing conditions like 'github.event_name == 'pull_request'' to work correctly when the parent workflow was triggered by a pull_request event.
Learnt from: Teebor-Choka
PR: hoprnet/hoprnet#6886
File: nix/rust-package.nix:84-84
Timestamp: 2025-02-25T00:35:33.437Z
Learning: When transitioning from vendored dependencies to a private proxy registry in Rust projects, GitHub Actions workflows need to be refactored to accommodate the new update strategy, particularly workflows handling dependency updates like renovate-cargo-update.yaml.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/build-dappnode.yaml:40-40
Timestamp: 2025-05-27T16:23:08.868Z
Learning: In the hoprnet repository's GitHub workflows, labels are passed from build.yaml to build-dappnode.yaml with a trailing comma using `format('{0},', join(github.event.pull_request.labels.*.name, ','))`. Therefore, the condition checks in build-dappnode.yaml correctly use `format('package:{0},', inputs.dappnode_repository)` with a trailing comma to match the exact label format and prevent false positives.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:07:29.649Z
Learning: In GitHub Actions reusable workflows, the github context from the caller workflow is inherited by the called workflow, so github.event_name reflects the original triggering event (e.g., 'pull_request') rather than being set to 'workflow_call'. Conditions like 'github.event_name == 'pull_request'' work correctly in reusable workflows when the parent workflow was triggered by that event type.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:08:43.091Z
Learning: In GitHub Actions reusable workflows, the github context from the caller workflow is inherited by the called workflow, so github.event_name reflects the original triggering event (e.g., 'pull_request') rather than being set to 'workflow_call'. Conditions like 'github.event_name == 'pull_request'' work correctly in reusable workflows when the parent workflow was triggered by that event type.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:08:43.091Z
Learning: In GitHub Actions reusable workflows, the github context from the caller workflow is inherited by the called workflow, so github.event_name reflects the original triggering event (e.g., 'pull_request') rather than being set to 'workflow_call'. Conditions like 'github.event_name == 'pull_request'' work correctly in reusable workflows when the parent workflow was triggered by that event type.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/add-labels.yaml:49-57
Timestamp: 2025-05-27T16:21:03.705Z
Learning: GitHub CLI (gh) accepts GITHUB_TOKEN as an environment variable for authentication in GitHub Actions workflows, not just GH_TOKEN. The environment variable GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} works correctly with gh commands like "gh pr edit".
Learnt from: tolbrino
PR: hoprnet/hoprnet#6502
File: flake.nix:12-14
Timestamp: 2024-09-30T08:27:16.849Z
Learning: The project already has CI workflows that automatically check for compatibility issues when updating dependencies, including compiling smart contracts with new Solidity versions, running the test suite, checking for compiler warnings or deprecation notices, and reviewing changelogs for breaking changes.
Learnt from: tolbrino
PR: hoprnet/hoprnet#6502
File: flake.nix:12-14
Timestamp: 2024-10-09T06:16:18.170Z
Learning: The project already has CI workflows that automatically check for compatibility issues when updating dependencies, including compiling smart contracts with new Solidity versions, running the test suite, checking for compiler warnings or deprecation notices, and reviewing changelogs for breaking changes.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7280
File: .github/workflows/checks-pre-commit.yaml:30-36
Timestamp: 2025-07-01T13:09:08.718Z
Learning: In the hoprnet repository's GitHub Actions workflow architecture, ausias-armesto prefers to centralize input resolution and fallback logic in the main checks.yaml workflow, which then calls individual reusable workflows like checks-pre-commit.yaml. The individual workflows are designed to be called primarily through the main workflow rather than directly, so fallback values in the individual workflows may be considered redundant.
.github/workflows/build-docker.yaml (11)
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/build-dappnode.yaml:40-40
Timestamp: 2025-05-27T16:23:08.868Z
Learning: In the hoprnet repository's GitHub workflows, labels are passed from build.yaml to build-dappnode.yaml with a trailing comma using `format('{0},', join(github.event.pull_request.labels.*.name, ','))`. Therefore, the condition checks in build-dappnode.yaml correctly use `format('package:{0},', inputs.dappnode_repository)` with a trailing comma to match the exact label format and prevent false positives.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#6681
File: .github/workflows/build-binaries.yaml:61-97
Timestamp: 2024-11-26T17:47:32.384Z
Learning: The code in the 'Set environment variables' step in `.github/workflows/build-binaries.yaml` is obsolete and should not be reviewed in future code reviews.
Learnt from: Teebor-Choka
PR: hoprnet/hoprnet#6886
File: nix/rust-package.nix:84-84
Timestamp: 2025-02-25T00:35:33.437Z
Learning: When transitioning from vendored dependencies to a private proxy registry in Rust projects, GitHub Actions workflows need to be refactored to accommodate the new update strategy, particularly workflows handling dependency updates like renovate-cargo-update.yaml.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:07:29.649Z
Learning: In GitHub Actions reusable workflows, the github.event_name context may inherit from the parent workflow rather than being set to 'workflow_call', allowing conditions like 'github.event_name == 'pull_request'' to work correctly when the parent workflow was triggered by a pull_request event.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#6635
File: .github/workflows/build-dappnode.yaml:51-52
Timestamp: 2024-11-14T17:33:28.735Z
Learning: In the `.github/workflows/build-dappnode.yaml` file, explicit error handling for GitHub API calls is not required.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7280
File: .github/workflows/checks-pre-commit.yaml:30-36
Timestamp: 2025-07-01T13:09:08.718Z
Learning: In the hoprnet repository's GitHub Actions workflow architecture, ausias-armesto prefers to centralize input resolution and fallback logic in the main checks.yaml workflow, which then calls individual reusable workflows like checks-pre-commit.yaml. The individual workflows are designed to be called primarily through the main workflow rather than directly, so fallback values in the individual workflows may be considered redundant.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/add-labels.yaml:49-57
Timestamp: 2025-05-27T16:21:03.705Z
Learning: GitHub CLI (gh) accepts GITHUB_TOKEN as an environment variable for authentication in GitHub Actions workflows, not just GH_TOKEN. The environment variable GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} works correctly with gh commands like "gh pr edit".
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/open-pr.yaml:83-95
Timestamp: 2025-06-30T08:36:01.731Z
Learning: The self-hosted-hoprnet-small runners in the hoprnet repository have GitHub CLI (gh) pre-installed and available for use in workflows.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:66-68
Timestamp: 2025-06-19T10:10:00.368Z
Learning: In the HOPR packaging workflow (.github/workflows/package.yaml), the `just package` command creates a single distribution package that includes all binaries (hoprd and hopli) for the target architecture. The workflow downloads both hoprd and hopli artifacts, extracts them to ./dist/bin, and nfpm packages both binaries together into one .deb, .rpm, or .apk file per target.
Learnt from: Teebor-Choka
PR: hoprnet/hoprnet#7142
File: .github/labeler.yml:95-106
Timestamp: 2025-05-26T22:04:22.750Z
Learning: In .github/labeler.yml, both legacy crate labels (like hopr-path, hopr-platform) and new crate labels (like hopr-chain-actions, hopr-chain-api) can coexist in the same file. When new crate labels are added, it doesn't necessarily mean old ones are deprecated or should be removed.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:0-0
Timestamp: 2025-06-19T11:37:27.410Z
Learning: In the HOPR packaging workflow (.github/workflows/package.yaml), both hoprd and hopli binaries are downloaded and used together in a single package creation process. The `just package` command creates one distribution package (.deb, .rpm, or .apk) per target that contains both binaries, which is why the workflow only uploads one package per format rather than separate packages for each binary.
🪛 actionlint (1.7.7)
.github/workflows/build-docker.yaml
148-148: if: condition "vars.CONTINUOUS_DEPLOYMENT_ENABLED == 'true' && ${{ inputs.package }} == 'hoprd' && contains(steps.pr-labels.outputs.labels, ' deploy_nodes ')" is always evaluated to true because extra characters are around ${{ }}
(if-cond)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: hopli / docker
- GitHub Check: hoprd / docker
- GitHub Check: Zizmor / Zizmor
- GitHub Check: Lint / Lint
- GitHub Check: Docs / Rust
🔇 Additional comments (1)
.github/workflows/build-docker.yaml (1)
151-151
: VerifyGH_RUNNER_TOKEN
scope & availabilitySwitching from the built-in
GITHUB_TOKEN
to a custom secret avoids token-permission limits from forked PRs, but:
- The secret must exist in all repos/environments where this reusable workflow runs, or dispatch will fail.
- The secret needs
repo
scope (at minimum) to invokerepository_dispatch
on the same repo.Please double-check that
GH_RUNNER_TOKEN
is configured accordingly and documented for anyone cloning this workflow.
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.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/build-docker.yaml (1)
148-148
:if:
mixes literal & expression → condition is always true
actionlint
is correct:${{ inputs.package }}
is expanded after the parser has already tokenised the expression, so the left-hand side of&&
becomes a bare string which coerces totrue
.
Keep the whole condition inside a single${{ … }}
block.- if: vars.CONTINUOUS_DEPLOYMENT_ENABLED == 'true' && ${{ inputs.package }} == 'hoprd' && contains(steps.pr-labels.outputs.labels, ' deploy_nodes ') + if: ${{ vars.CONTINUOUS_DEPLOYMENT_ENABLED == 'true' && + inputs.package == 'hoprd' && + contains(steps.pr-labels.outputs.labels, ' deploy_nodes ') }}
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
-
.github/workflows/build-docker.yaml
(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:07:29.649Z
Learning: In GitHub Actions reusable workflows, the github.event_name context may inherit from the parent workflow rather than being set to 'workflow_call', allowing conditions like 'github.event_name == 'pull_request'' to work correctly when the parent workflow was triggered by a pull_request event.
Learnt from: Teebor-Choka
PR: hoprnet/hoprnet#6886
File: nix/rust-package.nix:84-84
Timestamp: 2025-02-25T00:35:33.437Z
Learning: When transitioning from vendored dependencies to a private proxy registry in Rust projects, GitHub Actions workflows need to be refactored to accommodate the new update strategy, particularly workflows handling dependency updates like renovate-cargo-update.yaml.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/build-dappnode.yaml:40-40
Timestamp: 2025-05-27T16:23:08.868Z
Learning: In the hoprnet repository's GitHub workflows, labels are passed from build.yaml to build-dappnode.yaml with a trailing comma using `format('{0},', join(github.event.pull_request.labels.*.name, ','))`. Therefore, the condition checks in build-dappnode.yaml correctly use `format('package:{0},', inputs.dappnode_repository)` with a trailing comma to match the exact label format and prevent false positives.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:07:29.649Z
Learning: In GitHub Actions reusable workflows, the github context from the caller workflow is inherited by the called workflow, so github.event_name reflects the original triggering event (e.g., 'pull_request') rather than being set to 'workflow_call'. Conditions like 'github.event_name == 'pull_request'' work correctly in reusable workflows when the parent workflow was triggered by that event type.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:08:43.091Z
Learning: In GitHub Actions reusable workflows, the github context from the caller workflow is inherited by the called workflow, so github.event_name reflects the original triggering event (e.g., 'pull_request') rather than being set to 'workflow_call'. Conditions like 'github.event_name == 'pull_request'' work correctly in reusable workflows when the parent workflow was triggered by that event type.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:08:43.091Z
Learning: In GitHub Actions reusable workflows, the github context from the caller workflow is inherited by the called workflow, so github.event_name reflects the original triggering event (e.g., 'pull_request') rather than being set to 'workflow_call'. Conditions like 'github.event_name == 'pull_request'' work correctly in reusable workflows when the parent workflow was triggered by that event type.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/add-labels.yaml:49-57
Timestamp: 2025-05-27T16:21:03.705Z
Learning: GitHub CLI (gh) accepts GITHUB_TOKEN as an environment variable for authentication in GitHub Actions workflows, not just GH_TOKEN. The environment variable GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} works correctly with gh commands like "gh pr edit".
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/open-pr.yaml:83-95
Timestamp: 2025-06-30T08:36:01.731Z
Learning: The self-hosted-hoprnet-small runners in the hoprnet repository have GitHub CLI (gh) pre-installed and available for use in workflows.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7280
File: .github/workflows/checks-pre-commit.yaml:30-36
Timestamp: 2025-07-01T13:09:08.718Z
Learning: In the hoprnet repository's GitHub Actions workflow architecture, ausias-armesto prefers to centralize input resolution and fallback logic in the main checks.yaml workflow, which then calls individual reusable workflows like checks-pre-commit.yaml. The individual workflows are designed to be called primarily through the main workflow rather than directly, so fallback values in the individual workflows may be considered redundant.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#6681
File: .github/workflows/build-binaries.yaml:61-97
Timestamp: 2024-11-26T17:47:32.384Z
Learning: The code in the 'Set environment variables' step in `.github/workflows/build-binaries.yaml` is obsolete and should not be reviewed in future code reviews.
.github/workflows/build-docker.yaml (12)
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/build-dappnode.yaml:40-40
Timestamp: 2025-05-27T16:23:08.868Z
Learning: In the hoprnet repository's GitHub workflows, labels are passed from build.yaml to build-dappnode.yaml with a trailing comma using `format('{0},', join(github.event.pull_request.labels.*.name, ','))`. Therefore, the condition checks in build-dappnode.yaml correctly use `format('package:{0},', inputs.dappnode_repository)` with a trailing comma to match the exact label format and prevent false positives.
Learnt from: Teebor-Choka
PR: hoprnet/hoprnet#6886
File: nix/rust-package.nix:84-84
Timestamp: 2025-02-25T00:35:33.437Z
Learning: When transitioning from vendored dependencies to a private proxy registry in Rust projects, GitHub Actions workflows need to be refactored to accommodate the new update strategy, particularly workflows handling dependency updates like renovate-cargo-update.yaml.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:07:29.649Z
Learning: In GitHub Actions reusable workflows, the github.event_name context may inherit from the parent workflow rather than being set to 'workflow_call', allowing conditions like 'github.event_name == 'pull_request'' to work correctly when the parent workflow was triggered by a pull_request event.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#6681
File: .github/workflows/build-binaries.yaml:61-97
Timestamp: 2024-11-26T17:47:32.384Z
Learning: The code in the 'Set environment variables' step in `.github/workflows/build-binaries.yaml` is obsolete and should not be reviewed in future code reviews.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7280
File: .github/workflows/checks-pre-commit.yaml:30-36
Timestamp: 2025-07-01T13:09:08.718Z
Learning: In the hoprnet repository's GitHub Actions workflow architecture, ausias-armesto prefers to centralize input resolution and fallback logic in the main checks.yaml workflow, which then calls individual reusable workflows like checks-pre-commit.yaml. The individual workflows are designed to be called primarily through the main workflow rather than directly, so fallback values in the individual workflows may be considered redundant.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#6635
File: .github/workflows/build-dappnode.yaml:51-52
Timestamp: 2024-11-14T17:33:28.735Z
Learning: In the `.github/workflows/build-dappnode.yaml` file, explicit error handling for GitHub API calls is not required.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7191
File: .github/workflows/open-pr.yaml:83-95
Timestamp: 2025-06-30T08:36:01.731Z
Learning: The self-hosted-hoprnet-small runners in the hoprnet repository have GitHub CLI (gh) pre-installed and available for use in workflows.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:66-68
Timestamp: 2025-06-19T10:10:00.368Z
Learning: In the HOPR packaging workflow (.github/workflows/package.yaml), the `just package` command creates a single distribution package that includes all binaries (hoprd and hopli) for the target architecture. The workflow downloads both hoprd and hopli artifacts, extracts them to ./dist/bin, and nfpm packages both binaries together into one .deb, .rpm, or .apk file per target.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:07:29.649Z
Learning: In GitHub Actions reusable workflows, the github context from the caller workflow is inherited by the called workflow, so github.event_name reflects the original triggering event (e.g., 'pull_request') rather than being set to 'workflow_call'. Conditions like 'github.event_name == 'pull_request'' work correctly in reusable workflows when the parent workflow was triggered by that event type.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:28-28
Timestamp: 2025-06-19T10:08:43.091Z
Learning: In GitHub Actions reusable workflows, the github context from the caller workflow is inherited by the called workflow, so github.event_name reflects the original triggering event (e.g., 'pull_request') rather than being set to 'workflow_call'. Conditions like 'github.event_name == 'pull_request'' work correctly in reusable workflows when the parent workflow was triggered by that event type.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7297
File: deploy/nfpm/package-pre-uninstall.sh:4-7
Timestamp: 2025-07-10T11:28:36.192Z
Learning: In the HOPR project, when working with nfpm package scripts (like package-pre-uninstall.sh), certain error handling patterns like `|| true` and stderr redirection may interfere with lintian (Debian package checker) compliance requirements. The maintainer ausias-armesto prioritizes lintian compliance over defensive error handling in these scripts.
Learnt from: ausias-armesto
PR: hoprnet/hoprnet#7251
File: .github/workflows/package.yaml:0-0
Timestamp: 2025-06-19T11:37:27.410Z
Learning: In the HOPR packaging workflow (.github/workflows/package.yaml), both hoprd and hopli binaries are downloaded and used together in a single package creation process. The `just package` command creates one distribution package (.deb, .rpm, or .apk) per target that contains both binaries, which is why the workflow only uploads one package per format rather than separate packages for each binary.
🪛 actionlint (1.7.7)
.github/workflows/build-docker.yaml
148-148: if: condition "vars.CONTINUOUS_DEPLOYMENT_ENABLED == 'true' && ${{ inputs.package }} == 'hoprd' && contains(steps.pr-labels.outputs.labels, ' deploy_nodes ')" is always evaluated to true because extra characters are around ${{ }}
(if-cond)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
- GitHub Check: hoprd / docker
- GitHub Check: hopli / docker
- GitHub Check: Zizmor / Zizmor
- GitHub Check: Lint / Lint
- GitHub Check: Docs / Rust
- GitHub Check: tests-smart-contracts
- GitHub Check: tests-unit
- GitHub Check: Build Candidate Binaries (hopli)
- GitHub Check: tests-unit-nightly
- GitHub Check: Build Candidate Binaries (hoprd)
Tested using: #7307
It uses the correct github token and improves the conditionals syntax