Move actions to lhm_actions #8
Conversation
|
da fehlt zumindest das workflow template für code ql |
|
ich würde erst noch actionlint drüberlaufen lassen |
verstehe ich nicht. wir wollten doch die workflow templates von den actions in getrennten repos halten, die refarch-templates sollen die actions direkt verwenden. wozu brauch ich dann das codeql workflow template in lhm_actions? |
Passiert, sobald #5 im main ist und der main in diesen gemerged wird. |
https://github.com/it-at-m/.github/blob/main/.github/workflows/codeql.yml also hier ist ja keine Referenze drinnen. daher würde ich es auch verschieben. workflow templates app store ungeleich workflow templates. |
WalkthroughThis pull request introduces several new GitHub Actions workflows using the composite action approach. The changes add actions for building and deploying documentation (using VitePress and GitHub Pages), building and pushing Docker images, checking out code at a fixed commit, performing advanced CodeQL scans, and managing Maven and Node.js project builds and releases. Each action defines its own input parameters, execution steps, and output handling to streamline CI/CD processes. Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant Act as Composite Action
participant CO as Checkout
participant Env as Environment Setup
participant Build as Build/Test/Lint
participant Art as Artifact Upload
Dev->>Act: Trigger Build Workflow
Act->>CO: Checkout code
Act->>Env: Set up Node.js/JDK environment
Act->>Build: Run lint/test/build steps
Act->>Art: Generate & upload artifact
Art-->>Dev: Build artifact available
sequenceDiagram
participant Dev as Developer
participant Act as Composite Release Action
participant CO as Checkout
participant Env as Environment Setup
participant Tag as Version Bump & Tagging
participant Pub as Publish/Release
Dev->>Act: Trigger Release Workflow
Act->>CO: Checkout code
Act->>Env: Set up required environment
Act->>Tag: Bump version and create tag
Act->>Pub: Publish release artifact (Maven/Npm/GitHub Release)
Pub-->>Dev: Release complete
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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
|
Hier: https://github.com/it-at-m/.github/blob/c64e88efc99a9fb992dc4ca4e0afc26ed34fd123/.github/workflows/codeql.yml#L83C9-L83C65 z.B. wird doch auf die action codeql im .github-Repo referenziert. Ich würde es deshalb nicht verschieben bzw. in ..github/github/workflows einfach löschen. Es gibt ja auch noch: .github/workflow-templates/codeql.yaml Aber was ist mit .github/workflows/deploy-pages.yml, das hat tatsächlich keine Referenzen. |
…ithub copied to lhm_actions
Das mit dem CodeQL ist etwas anders als die anderen Workflows und Actions. Die Aufrufe sind wie folgt .github/workflow-templates/codeql.yaml -> .github/.github/workflows/codeql.yaml -> .github(bzw. lhm_actions)/.github/actions/action-codeql.yaml - ich schlage vor: wir lassen die workflows erstmal beide in .github und ziehen nur die Action um und wir schauen uns das nochmal in Ruhe an. ob bzw. wie wir verbessern können. |
|
deploy-pages würde ich entfernen. das pflegen wir nur in refarch-templates |
|
ich würde jetzt erst noch das linting abwarten und sonst passts |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 18
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (13)
.github/actions/action-build-docs/action.yml(1 hunks).github/actions/action-build-image/action.yml(1 hunks).github/actions/action-checkout/action.yml(1 hunks).github/actions/action-codeql/action.yml(1 hunks).github/actions/action-create-github-release/action.yml(1 hunks).github/actions/action-deploy-docs/action.yml(1 hunks).github/actions/action-maven-build/action.yml(1 hunks).github/actions/action-maven-release/action.yml(1 hunks).github/actions/action-npm-build/action.yml(1 hunks).github/actions/action-npm-release/action.yml(1 hunks).github/workflows/deploy-pages.yaml(1 hunks)CODE_OF_CONDUCT.md(1 hunks)README.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
README.md
[style] ~43-~43: Consider using a shorter alternative to avoid wordiness.
Context: ...*. If you have a suggestion that would make this better, please open an issue with the tag "enh...
(MADE_IT_JJR)
🪛 YAMLlint (1.35.1)
.github/actions/action-maven-build/action.yml
[warning] 21-21: too few spaces before comment
(comments)
[warning] 23-23: too few spaces before comment
(comments)
[warning] 37-37: too few spaces before comment
(comments)
[error] 41-41: no new line character at the end of file
(new-line-at-end-of-file)
.github/actions/action-npm-release/action.yml
[error] 14-14: wrong indentation: expected 4 but found 8
(indentation)
[error] 20-20: trailing spaces
(trailing-spaces)
[error] 22-22: wrong indentation: expected 4 but found 5
(indentation)
[error] 25-25: trailing spaces
(trailing-spaces)
[error] 26-26: wrong indentation: expected 4 but found 3
(indentation)
[error] 29-29: trailing spaces
(trailing-spaces)
[error] 33-33: too many spaces after colon
(colons)
[error] 34-34: trailing spaces
(trailing-spaces)
[error] 35-35: wrong indentation: expected 4 but found 5
(indentation)
[error] 36-36: trailing spaces
(trailing-spaces)
[error] 39-39: wrong indentation: expected 2 but found 4
(indentation)
[warning] 42-42: too few spaces before comment
(comments)
[warning] 44-44: too few spaces before comment
(comments)
[error] 66-66: too many spaces after colon
(colons)
[warning] 72-72: too few spaces before comment
(comments)
.github/workflows/deploy-pages.yaml
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
[warning] 48-48: too few spaces before comment
(comments)
[warning] 50-50: too few spaces before comment
(comments)
[warning] 52-52: too few spaces before comment
(comments)
[warning] 58-58: too few spaces before comment
(comments)
[warning] 64-64: too few spaces before comment
(comments)
[error] 79-79: no new line character at the end of file
(new-line-at-end-of-file)
.github/actions/action-npm-build/action.yml
[error] 20-20: trailing spaces
(trailing-spaces)
[error] 21-21: trailing spaces
(trailing-spaces)
[warning] 27-27: too few spaces before comment
(comments)
[warning] 29-29: too few spaces before comment
(comments)
[warning] 52-52: too few spaces before comment
(comments)
.github/actions/action-maven-release/action.yml
[warning] 55-55: too few spaces before comment
(comments)
[warning] 57-57: too few spaces before comment
(comments)
[warning] 87-87: too few spaces before comment
(comments)
[error] 91-91: no new line character at the end of file
(new-line-at-end-of-file)
.github/actions/action-codeql/action.yml
[warning] 31-31: too few spaces before comment
(comments)
[warning] 34-34: too few spaces before comment
(comments)
[error] 54-54: no new line character at the end of file
(new-line-at-end-of-file)
🔇 Additional comments (44)
.github/actions/action-checkout/action.yml (2)
1-2: Action Declaration: Clear and Concise
The name and description provide a succinct purpose for the action.
4-8: Composite Action Setup: Proper Implementation
The composite action is configured correctly with the appropriate steps. The explicit commit reference in the checkout usage ensures reproducibility..github/actions/action-deploy-docs/action.yml (2)
1-13: Input Parameter Definitions: Well-Defined and Flexible
Both theartifact_nameanddeploy-branchinputs are clearly described and include sensible default values, which facilitates easy customization.
14-24: Deployment Job: Solid Composite Step Configuration
The deployment steps, including the conditional execution ongithub.ref_name, are correctly implemented. While the parentheses in the condition on line 20 are not required, they do not affect functionality..github/actions/action-create-github-release/action.yml (1)
16-33: Composite Action Steps: Clean and Functional
The steps for downloading the artifact and creating the GitHub release are structured well. Keeping explicit commit references for the used actions is a good practice for stability..github/actions/action-maven-build/action.yml (1)
3-12: Input and Output Configuration: Clear and Effective
The inputs (java-versionandapp-path) and the output (artifact-name) are properly defined, making the workflow easily configurable for various Maven projects..github/actions/action-build-docs/action.yml (2)
4-25: Input Parameters: Configured for Flexibility
The inputs fordocs-path,node-version,build-cmd, anddist-pathare well-defined with descriptive defaults, facilitating a flexible documentation build process.
26-54: Composite Steps: Well-Structured and Cohesive Workflow
The sequential steps—checkout, Node setup (including caching), pages configuration, dependency installation, linting, building with VitePress, and artifact uploading—are clearly organized and align with best practices for CI/CD processes..github/actions/action-npm-build/action.yml (7)
1-7: Workflow Name and Node Version Input ValidationThe workflow name "Compliance check and build test" is clear, and the inputs (especially the Node.js version) are defined with an appropriate default value.
12-19: Lint and Test Inputs VerificationThe optional flags
run-lintandrun-testare set as strings with default'true', which is acceptable if the implementation expects string comparison.
24-26: Composite Runner SetupThe composite runner configuration under
runs:is correctly declared. Everything appears in order here.
27-30: Checkout and Node Setup StepsThe checkout step and the Node.js setup step (with fixed commit hashes) are properly integrated. Ensure the commit references remain up to date with secure and stable releases.
🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 27-27: too few spaces before comment
(comments)
[warning] 29-29: too few spaces before comment
(comments)
34-47: Installation, Lint, Test, and Build StepsThe steps to install dependencies, and the conditional execution of lint, test, and build scripts are well structured and use the
--prefixargument appropriately.
48-50: Artifact Name Computation StepThe step using the
hashFilesfunction to compute an artifact name is innovative. Please double-check that the runner environment supports this function as expected.
51-56: Artifact Upload Step VerificationThe "Upload Artifact" step correctly uses the
actions/upload-artifactaction with a defined retention period and artifact path. Ensure that the glob pattern "**/dist" reliably captures all intended build artifacts.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 52-52: too few spaces before comment
(comments)
README.md (1)
1-68: Overall README Update ApprovalThe README modifications, including the updated terminology (replacing "repo" with "repository"), improve clarity and consistency throughout the document.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~28-~28: Possible missing comma found.
Context: ...ctions in your project. To start with actions read the [GitHub Actions documentation]...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~41-~41: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...buting Contributions are what make the open source community such an amazing place to lear...(EN_COMPOUND_ADJECTIVE_INTERNAL)
[style] ~41-~41: Consider using a more formal and expressive alternative to ‘amazing’.
Context: ...hat make the open source community such an amazing place to learn, inspire, and create. An...(AWESOME)
[style] ~43-~43: Consider using a shorter alternative to avoid wordiness.
Context: ...*. If you have a suggestion that would make this better, please open an issue with the tag "enh...(MADE_IT_JJR)
.github/actions/action-build-image/action.yml (7)
1-3: Workflow Name and Description VerificationThe "Build Docker Image" workflow is clearly identified, and its purpose is concisely described.
35-38: Composite Action Runner ConfigurationThe configuration specifying
runs: using: "composite"is set correctly, ensuring that subsequent steps are executed in sequence.
38-40: Checkout Step VerificationThe checkout step correctly utilizes a fixed commit hash, ensuring that the action runs against a specific, verified version of the code.
40-44: Artifact Download Step ReviewThe step to download a single artifact is configured accurately. Confirm that the input used for artifact name aligns with the output generated in the related npm build workflow.
44-50: Docker Registry Login StepThe login step employs the
docker/login-actionwith proper inputs for the registry, username, and password. Verify that these credentials conform to your registry’s authentication requirements.
51-58: Metadata Extraction Step VerificationThe metadata extraction step is well implemented using
docker/metadata-action. Ensure that the generated image name using${{ inputs.registry }}/${{ github.repository }}/${{ inputs.image-name }}fits your naming conventions.
59-65: Image Build and Push Step ValidationThe final step, which builds and pushes the Docker image, is set up appropriately with the provided context and dynamic tags/labels. Ensure that the context path (
./${{ inputs.path }}) accurately reflects the directory structure of the repository..github/actions/action-npm-release/action.yml (4)
1-12: Npm Release Action: Basic Setup VerificationThe workflow name and initial input definitions (for
node-versionandapp-path) are clear and well documented.
38-62: Version Bump and Tag Creation StepThe version bump step leveraging
npm versionand subsequent git commands is correctly implemented. Verify that the new version information is properly utilized in downstream processes.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 39-39: wrong indentation: expected 2 but found 4
(indentation)
[warning] 42-42: too few spaces before comment
(comments)
[warning] 44-44: too few spaces before comment
(comments)
67-73: Conditional Deployment StepThe conditional deployment step is well constructed, ensuring that the
npm publishcommand is executed only whenskip-deploymentis false. The use of theNODE_AUTH_TOKENenvironment variable is appropriate.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 72-72: too few spaces before comment
(comments)
63-66: 🧹 Nitpick (assertive)Composite Action Reference Check
The step with id
nodecalls the npm build action using:uses: it-at-m/.github/.github/actions/action-npm-build@mainPlease confirm that this reference path aligns with the intended relocation under
lhm_actionsor if it needs to be updated.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 66-66: too many spaces after colon
(colons)
.github/workflows/deploy-pages.yaml (6)
1-10: Deploy Pages Workflow: Input DefinitionsThe input parameters (
sub-path,node-version,build-cmd, anddist-path) are defined coherently with sensible defaults. Double-check that these defaults align with your VitePress project’s structure.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
27-32: Permissions Configuration CheckThe permissions for
contents,pages, andid-tokenare correctly set to enable deployment to GitHub Pages.
33-38: Concurrency Settings ReviewThe concurrency settings ensure only one deployment runs at a time without canceling in-progress jobs. This configuration is appropriate for production deployments.
39-51: Build Job Configuration VerificationThe
buildjob is configured to check out the repository, set up Node.js (with caching), configure Pages, install dependencies, and build the VitePress project. Confirm that theworking-directoryand cache paths correctly reflect your project structure.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 48-48: too few spaces before comment
(comments)
[warning] 50-50: too few spaces before comment
(comments)
52-67: Artifact Upload Step in Build JobThe artifact upload step uses
actions/upload-pages-artifactwith the path based on the concatenation ofsub-pathanddist-path. Ensure that this combined path accurately points to your deployed site's build output.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 52-52: too few spaces before comment
(comments)
[warning] 58-58: too few spaces before comment
(comments)
[warning] 64-64: too few spaces before comment
(comments)
68-79: Deploy Job and Deployment StepThe
deployjob correctly depends on thebuildjob and usesactions/deploy-pagesto publish the site. Verify that the deployment output variable (page_url) is correctly captured for further use.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 79-79: no new line character at the end of file
(new-line-at-end-of-file)
.github/actions/action-codeql/action.yml (6)
1-2: Action Header is Clear and Informative
The action’s name and description clearly explain its purpose.
30-32: Checkout Step Reviewed
Using a fixed commit hash for the checkout action improves reproducibility. Note the YAML linter warning: on line 31, the comment should be preceded by proper spacing.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 31-31: too few spaces before comment
(comments)
32-39: JDK Setup Step is Correct
The conditional execution for setting up the JDK is handled properly. Please note the YAML linter warning on line 34: adjust spacing before the comment for consistency.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 34-34: too few spaces before comment
(comments)
40-45: CodeQL Initialization is Clear
The initialization step correctly passes the inputs to the CodeQL action.
46-50: Autobuild Step is Implemented Appropriately
The conditional step for autobuild is implemented using the appropriate input check.
51-54: CodeQL Analysis Step is Configured Correctly
The action step for performing the CodeQL analysis uses the provided inputs appropriately.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 54-54: no new line character at the end of file
(new-line-at-end-of-file)
.github/actions/action-maven-release/action.yml (4)
1-2: Maven Release Workflow Header Looks Good
The action’s name “Maven Release” is appropriately declared.
21-24: Input Parameter: skipDeployment
The boolean input to skip deployment is correctly defined with a sensible default.
42-49: Output Parameters Are Set Up Correctly
The outputs MVN_ARTIFACT_ID and artifact-name properly reference the outputs from subsequent steps.
83-86: Artifact Name Calculation is Fine
The step that calculates the artifact name using the hashFiles function is correctly implemented.CODE_OF_CONDUCT.md (1)
55-55: Standardized Email Address Terminology
Changing “official e-mail address” to “official email address” improves consistency and modernizes the language used in the document.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.github/actions/action-create-github-release/action.yml(1 hunks).github/actions/action-npm-build/action.yml(1 hunks)
🔇 Additional comments (14)
.github/actions/action-create-github-release/action.yml (4)
1-2: Action Metadata Definition
The action’s name and description are clear and directly reflect its purpose: to create a GitHub Release for a Maven artifact.
3-15: Input Definitions Clarity
All required inputs (artifact-name,tag-name, andartifact-path) are well defined with appropriate types and descriptive texts. The descriptions clearly indicate what each input represents. If needed, you might consider adding a note about supporting multiple files inartifact-pathfor greater flexibility.
16-23: Composite Action and Artifact Download Step
The action is configured as a composite run, and the first step successfully downloads the specified artifact using a pinned version ofactions/download-artifact. Pinning to a specific commit hash is good for reproducibility. Just ensure that you periodically review and update the pins as new stable versions are released.
24-32: GitHub Release Creation Step
The step usingsoftprops/action-gh-releasecorrectly sets the release parameters (non-draft, non-prerelease, no auto-generated notes) and passes the tag name and files from inputs. Confirm that the file pattern provided inartifact-pathreliably matches the generated artifacts..github/actions/action-npm-build/action.yml (10)
1-7: Workflow Title and Node Version Input
The workflow title "Compliance check and build test" is straightforward. Thenode-versioninput is established with a sensible default. Consider expanding the description (e.g., "Specify the Node.js version to use for the build process") for enhanced clarity.
8-11: App-Path Input Enhancement
Theapp-pathinput is marked as required to indicate where thepackage.jsonis located. For better guidance, consider adding an example (e.g.,./app) in the description.
12-19: Lint and Test Flag Inputs
The inputsrun-lintandrun-testare straightforward and allow conditional execution of linting and testing commands. Their descriptions clearly communicate their purpose.
24-33: Environment Setup Steps
The steps that checkout the code and set up Node.js (with caching enabled via the package-lock path) are configured appropriately. Using pinned commit hashes (for bothactions/checkoutandactions/setup-node) is a good practice for stability; just remember to review these pins periodically for upgrades.
34-36: Dependencies Installation
The command to install dependencies usingnpm ciscoped to the specifiedapp-pathis precise and aligns with best practices for CI environments.
37-40: Conditional Lint Execution
The linting step is correctly guarded by a conditional based on therun-lintflag. Usingnpm run --prefix ./\${{inputs.app-path}} lintis a solid approach provided that the lint script is defined in the package configuration.
41-44: Conditional Test Execution
The test execution step is also conditionally triggered by therun-testinput. Ensure that the testing script exists in the project's configuration.
45-47: Build Step
The build step usesnpm run buildwith the appropriate prefix. Make sure that the build output is directed to match the path expected later (i.e., within directories matching "**/dist").
48-50: Artifact Name Generation
Generating a unique artifact name using the hash of thepackage.jsonfile is a robust and innovative solution. Confirm that thehashFilesfunction is supported in this context and that its output meets your versioning or artifact-tracking requirements.
51-56: Artifact Upload Step
The final step correctly uploads the artifact using the generated name and specifies a retention period of 5 days. Verify that the output directory pattern "**/dist" aligns with your build artifacts.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/actions/action-maven-release/action.yml (1)
4-12: 🧹 Nitpick (assertive)Input Parameters: Consider Capitalizing Descriptions
The description for the "java-version" and "app-path" inputs is written in lowercase (e.g., "configure the java version"). For improved readability and consistency, consider capitalizing these descriptions (e.g., "Configure the Java version" and "Path where the pom.xml is located").
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/actions/action-maven-release/action.yml(1 hunks)
🧰 Additional context used
📓 Learnings (1)
.github/actions/action-maven-release/action.yml (1)
Learnt from: ejcsid
PR: it-at-m/lhm_actions#8
File: .github/actions/action-maven-release/action.yml:55-57
Timestamp: 2025-02-06T15:12:53.842Z
Learning: In YAML files within the repository, comment spacing after commit hashes is managed by Renovate bot and should not be manually modified.
🪛 YAMLlint (1.35.1)
.github/actions/action-maven-release/action.yml
[warning] 55-55: too few spaces before comment
(comments)
[warning] 57-57: too few spaces before comment
(comments)
[warning] 87-87: too few spaces before comment
(comments)
[error] 91-91: no new line character at the end of file
(new-line-at-end-of-file)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Lint
🔇 Additional comments (8)
.github/actions/action-maven-release/action.yml (8)
13-20: Input Parameters (Versioning): Well Defined
The "releaseVersion" and "developmentVersion" inputs are clearly described and consistent with common versioning terminology.
25-40: Input Parameters (Deployment Credentials): Clear and Secure
The deployment credential inputs (“SIGN_KEY_PASS”, “CENTRAL_USERNAME”, “CENTRAL_PASSWORD”, and “GPG_PRIVATE_KEY”) are defined clearly, helping ensure secure configuration during the Maven release process.
42-49: Outputs Section: Clarity and Correctness
The outputs "MVN_ARTIFACT_ID" and "artifact-name" are well described and properly reference the results from the Maven release steps.
54-57: Checkout and JDK Setup: Inline Comment Spacing
The inline comments at the end of the commit hash references (lines 55 and 57) trigger YAML lint warnings due to limited spacing. Since these spacings are managed automatically by Renovate bot, no manual adjustments are required.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 55-55: too few spaces before comment
(comments)
[warning] 57-57: too few spaces before comment
(comments)
83-85: Artifact Name Step: Implementation Check
The artifact name is generated using a hashFiles function, which is a valid approach for ensuring artifact uniqueness. No changes are required in this step.
60-62: 🧹 Nitpick (assertive)Cache Dependency Path: Correct File Path Formatting
The current file path is defined as ".${{ inputs.app-path}}/pom.xml" on line 62. This may lead to incorrect path resolution (e.g., resulting in ".my-app/pom.xml" instead of the intended "./my-app/pom.xml"). Consider updating this to prepend "./" for clarity and correctness.Proposed diff:
- cache-dependency-path: ".${{ inputs.app-path}}/pom.xml" + cache-dependency-path: "./${{ inputs.app-path}}/pom.xml"Likely invalid or redundant comment.
78-81:⚠️ Potential issueMaven Release Step: Correct Environment Variable Mapping
The environment variable mapping for SIGN_KEY_PASS on line 79 is incorrect—it currently assigns the value of GPG_PRIVATE_KEY instead of the GPG passphrase. This misconfiguration may lead to authentication issues during the release process.Proposed diff:
- SIGN_KEY_PASS: ${{ inputs.GPG_PRIVATE_KEY }} + SIGN_KEY_PASS: ${{ inputs.SIGN_KEY_PASS }}Likely invalid or redundant comment.
68-78: 🧹 Nitpick (assertive)Maven Release Step: File Path Consistency in Maven Commands
Within the Maven Release step, the Maven commands on lines 74 and 77 reference the pom.xml file using ".${{inputs.app-path}}/pom.xml". To handle potential spaces in folder names and for clarity, consider updating these commands to use a "./" prefix and enclosing the file path in quotes.Proposed changes:
- MVN_ARTIFACT_ID=$(mvn -f .${{inputs.app-path}}/pom.xml org.apache.maven.plugins:maven-help-plugin:3.2.0:evaluate -Dexpression=project.artifactId -q -DforceStdout) + MVN_ARTIFACT_ID=$(mvn -f "./${{inputs.app-path}}/pom.xml" org.apache.maven.plugins:maven-help-plugin:3.2.0:evaluate -Dexpression=project.artifactId -q -DforceStdout) ... - mvn release:prepare release:perform -f .${{inputs.app-path}}/pom.xml -B -DreleaseVersion=${{ inputs.releaseVersion }} -DdevelopmentVersion=${{ inputs.developmentVersion }} -Darguments="-Dmaven.deploy.skip=${{ inputs.skipDeployment }}" + mvn release:prepare release:perform -f "./${{inputs.app-path}}/pom.xml" -B -DreleaseVersion=${{ inputs.releaseVersion }} -DdevelopmentVersion=${{ inputs.developmentVersion }} -Darguments="-Dmaven.deploy.skip=${{ inputs.skipDeployment }}"Likely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (2)
.github/actions/action-codeql/action.yml (1)
55-55: File End Newline
Ensure a newline is present at the end of the file to satisfy YAML lint requirements..github/actions/action-maven-release/action.yml (1)
92-92: File End Newline
Please add a newline at the end of the file to comply with YAML lint standards.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (7)
-
.github/actions/action-codeql/action.yml(1 hunks) -
.github/actions/action-deploy-docs/action.yml(1 hunks) -
.github/actions/action-maven-build/action.yml(1 hunks) -
.github/actions/action-maven-release/action.yml(1 hunks) -
.github/actions/action-npm-build/action.yml(1 hunks) -
.github/actions/action-npm-release/action.yml(1 hunks) -
.github/workflows/deploy-pages.yaml(1 hunks)
🧰 Additional context used
📓 Learnings (2)
.github/actions/action-maven-release/action.yml (1)
Learnt from: ejcsid
PR: it-at-m/lhm_actions#8
File: .github/actions/action-maven-release/action.yml:55-57
Timestamp: 2025-02-06T15:12:53.842Z
Learning: In YAML files within the repository, comment spacing after commit hashes is managed by Renovate bot and should not be manually modified.
.github/actions/action-maven-build/action.yml (1)
Learnt from: ejcsid
PR: it-at-m/lhm_actions#8
File: .github/actions/action-maven-build/action.yml:19-41
Timestamp: 2025-02-06T15:03:26.447Z
Learning: Comments with version hashes (e.g., `@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2`) in GitHub Actions workflow files are managed by Renovate bot and should not be manually modified.
🪛 YAMLlint (1.35.1)
.github/actions/action-npm-release/action.yml
[error] 29-29: trailing spaces
(trailing-spaces)
[error] 33-33: too many spaces after colon
(colons)
[warning] 41-41: too few spaces before comment
(comments)
[warning] 43-43: too few spaces before comment
(comments)
[error] 65-65: too many spaces after colon
(colons)
[warning] 71-71: too few spaces before comment
(comments)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Lint
- GitHub Check: Lint
🔇 Additional comments (50)
.github/actions/action-deploy-docs/action.yml (2)
1-12: Clear Input Definitions
The inputs (artifact_name and deploy-branch) are defined clearly with appropriate defaults, types, and descriptions.
13-22: Composite Action Structure & Conditional Step
The composite action’s structure is straightforward and the deployment step is conditionally executed on line 18. Please verify that the expression (github.ref_name == inputs.deploy-branch) is evaluated as expected in this composite context—some setups expect expressions wrapped in ${{ … }}..github/actions/action-maven-build/action.yml (5)
3-12: Well-Defined Java Inputs
The input parameters for java-version and app-path are clear with meaningful defaults and concise descriptions.
13-16: Output Parameter Using HashFiles
The output 'artifact-name' leverages hashFiles effectively to generate a unique identifier for the artifact.
19-27: Checkout and JDK Setup
The steps for checking out the repository and setting up the JDK (with a pinned version and caching enabled) are well organized. Note that the version pins are maintained by Renovate and should not be manually altered.
28-30: Maven Build Command
The Maven build invocation is clear and uses the provided app-path to locate the pom.xml correctly.
31-40: Artifact Generation & Upload
The steps that generate the artifact name using hashFiles and upload the artifact are implemented correctly..github/actions/action-npm-build/action.yml (5)
1-11: Node.js & Application Path Inputs
The inputs for node-version, app-path, run-lint, and run-test are clearly specified. As mentioned in previous reviews for similar workflows, consider augmenting the app-path description with an example (e.g. "./app") for added guidance.
20-23: Artifact Output Definition
The output 'artifact-name' is appropriately defined using the output from the designated step.
26-33: Checkout and Node.js Setup
The composite steps for checking out the repository and setting up Node.js (with caching configured via package-lock.json) are clear and use the correct pinned versions.
34-44: Dependency Installation, Linting & Testing
The script conditionally executes lint and test commands based on the provided input flags, which is a neat way to control workflow behavior.
45-57: Build, Artifact Generation & Upload
The steps to run the build, generate an artifact using hashFiles, and then upload it are implemented correctly and maintain consistency with the other workflows..github/actions/action-npm-release/action.yml (6)
3-12: Consistent Node.js and App Inputs
The node-version and app-path inputs mirror those in other workflows. As before, adding an example to the app-path description can help clarify the expected input format.
13-28: Release & Deployment Inputs
Inputs for releaseVersion, skip-deployment, and npm-token are defined with correct types and helpful descriptions. The choice options for releaseVersion enforce Semantic Versioning increments which is appropriate.
37-61: Version Bump and Tagging Script
The script for bumping the version, creating a git tag, and pushing the changes (lines 49-61) is well structured with proper error handling using "|| exit 1". Ensure that the version format output by npm version fits your tagging convention.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 41-41: too few spaces before comment
(comments)
[warning] 43-43: too few spaces before comment
(comments)
62-69: Chaining Build Action & Conditional Deployment
The reuse of the npm build action (line 62-65) is a good design choice. Also, the condition for deployment (line 66) is implemented using an expression. Verify that the negation syntax "${{ !inputs.skip-deployment }}" behaves as intended.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 65-65: too many spaces after colon
(colons)
70-71: Secure Token Usage
Passing NODE_AUTH_TOKEN to the publish command securely ensures that the npm token is used properly during deployment.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 71-71: too few spaces before comment
(comments)
30-36: 🧹 Nitpick (assertive)Output Formatting – Cleanup Recommended
The outputs are correctly defined; however, in the ARTIFACT_NAME output (line 33) there are extra spaces after the colon. Consider removing them for cleaner YAML formatting. For example:- value: ${{ steps.node.outputs.artifact-name }} + value: ${{ steps.node.outputs.artifact-name }}Likely invalid or redundant comment.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 33-33: too many spaces after colon
(colons)
.github/workflows/deploy-pages.yaml (6)
3-25: Workflow-Call Inputs for Deployment
All inputs (sub-path, node-version, build-cmd, and dist-path) are clearly defined with sensible defaults and descriptive text.
27-31: Proper Permissions & Security
The permissions set for the GITHUB_TOKEN and the configuration for id-token and pages are appropriate for deploying to GitHub Pages.
33-37: Concurrency Settings
The concurrency configuration is clear and explicitly prevents cancelation of in-progress deployments while limiting concurrent runs.
39-67: Build Job Structure
The build job is well organized: it checks out the repository, sets up Node.js (with caching), installs dependencies, runs the build using the provided build command, and finally uploads the built artifact.
68-79: Deployment Job Execution
The deploy job correctly depends on the build job and uses the deploy-pages action with a pinned version. Ensure that the URL output from the deployment step (line 72) is as expected for post-deployment references.
80-80: Newline at End of File
A newline at the end of the file is recommended to satisfy YAML lint requirements..github/actions/action-codeql/action.yml (11)
1-3: Clear and Concise Action Metadata
The action’s name and description clearly communicate its purpose and functionality.
5-8: Well-defined Input: codeql-language
The 'codeql-language' input is documented with a helpful reference link and clear description.
9-13: Robust Configuration: codeql-buildmode
The 'codeql-buildmode' input is appropriately defined with a default value of "none" and includes a useful documentation link.
14-18: Clear and Customizable Input: codeql-query
The 'codeql-query' parameter is clear, provides a sensible default, and explains its purpose well.
19-22: Appropriate Default for Java Version
The 'java-version' input is defined with an explicit default and type. Although it’s effectively optional, consider explicitly marking its optional nature in the description if needed.
23-26: Consistent Input for File Path
The 'path' parameter is straightforward and defaults to the current directory, which meets the intended use.
30-31: Stable Repository Checkout
The checkout step uses a fixed commit hash, which helps ensure build consistency and security.
32-39: Conditional JDK Setup for Java Projects
The JDK setup is conditionally executed when 'codeql-language' is 'java-kotlin' and 'codeql-buildmode' is 'autobuild'. The configuration, including caching, is well implemented.
40-45: Effective Initialization of CodeQL
The CodeQL initialization step properly passes the input parameters (languages, build mode, and queries) to the action.
46-50: Conditional Build Step with Autobuild
The autobuild step is correctly gated by the 'codeql-buildmode' condition and uses the specified working directory.
51-54: Comprehensive CodeQL Analysis Execution
The analysis step constructs a category string combining the language and path inputs. Verify that this concatenated string meets your filtering and logging needs during analysis..github/actions/action-maven-release/action.yml (15)
1-2: Clear Action Naming for Maven Release
The action name "Maven Release" and its initial description effectively convey its purpose.
9-12: Input Parameter: app-path
The 'app-path' parameter clearly indicates where the pom.xml is located. You might consider clarifying that this should be a relative path from the repository root.
13-16: Input Parameter Clarity: releaseVersion
The releaseVersion input is straightforward with a clear description about the version to be released.
17-20: Input Parameter Clarity: developmentVersion
The developmentVersion input is defined clearly, indicating the upcoming snapshot version.
21-24: Input Parameter: skipDeployment
The skipDeployment flag is appropriately configured with a default, providing control over deployment behavior.
25-28: Input Parameter: SIGN_KEY_PASS
This input gathers the GPG private key passphrase. The description is concise and accurate.
29-32: Input Parameter: CENTRAL_USERNAME
The CENTRAL_USERNAME input is defined with a clear description for deployment credentials.
33-36: Input Parameter: CENTRAL_PASSWORD
The CENTRAL_PASSWORD input is clearly defined and appropriately described.
37-40: Input Parameter: GPG_PRIVATE_KEY
Renaming from GDP_PRIVATE_KEY to GPG_PRIVATE_KEY improves clarity and aligns with standard terminology.
54-55: Stable Code Checkout
The checkout step uses a fixed commit hash to ensure consistent behavior across runs.
83-86: Artifact Name Computation
The step deriving 'artifact-name' via a hashFiles function is a creative solution to generate a unique artifact identifier.
87-91: Artifact Upload Configuration
The Upload Artifact step is configured with a clear retention policy and correct usage of inputs. Ensure any YAML lint issues regarding inline comments or missing spacing are acceptable, especially if managed by Renovate.
56-67: 🛠️ Refactor suggestionJDK Setup with Maven Caching
The setup step utilizes actions/setup-java with caching configured. However, the 'cache-dependency-path' is currently set as:- cache-dependency-path: ".${{ inputs.app-path}}/pom.xml" + cache-dependency-path: "./${{ inputs.app-path}}/pom.xml"Using "./" ensures the relative path is correctly interpreted.
Likely invalid or redundant comment.
78-82:⚠️ Potential issueCorrect Environment Variable Mapping for GPG Passphrase
The environment variable SIGN_KEY_PASS is currently set to ${{ inputs.GPG_PRIVATE_KEY }}, which is incorrect. It should be mapped to ${{ inputs.SIGN_KEY_PASS }} to pass the correct GPG key passphrase:- SIGN_KEY_PASS: ${{ inputs.GPG_PRIVATE_KEY }} + SIGN_KEY_PASS: ${{ inputs.SIGN_KEY_PASS }}Likely invalid or redundant comment.
68-77: 🛠️ Refactor suggestionMaven Release Execution and Relative Path Consistency
Within the Maven release step, the Maven commands reference the pom.xml via ".${{inputs.app-path}}/pom.xml". Update these to use a leading "./" for correct path resolution:- mvn -f .${{inputs.app-path}}/pom.xml + mvn -f "./${{ inputs.app-path}}/pom.xml"This change should be applied consistently within this step.
Likely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 6
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/actions/action-npm-release/action.yml(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.35.1)
.github/actions/action-npm-release/action.yml
[error] 29-29: trailing spaces
(trailing-spaces)
[error] 33-33: too many spaces after colon
(colons)
[warning] 41-41: too few spaces before comment
(comments)
[warning] 43-43: too few spaces before comment
(comments)
[error] 65-65: too many spaces after colon
(colons)
[warning] 71-71: too few spaces before comment
(comments)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Lint
- GitHub Check: Lint
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (1)
.github/actions/action-maven-release/action.yml (1)
4-8: 🧹 Nitpick (assertive)Consistency: Capitalize 'java-version' Description
For consistency with repository standards and previous feedback, consider capitalizing the description, e.g., change "configure the java version" to "Configure the Java version".
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/actions/action-maven-release/action.yml(1 hunks)
🧰 Additional context used
📓 Learnings (1)
.github/actions/action-maven-release/action.yml (1)
Learnt from: ejcsid
PR: it-at-m/lhm_actions#8
File: .github/actions/action-maven-release/action.yml:55-57
Timestamp: 2025-02-06T15:12:53.842Z
Learning: In YAML files within the repository, comment spacing after commit hashes is managed by Renovate bot and should not be manually modified.
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Lint
- GitHub Check: Lint
🔇 Additional comments (7)
.github/actions/action-maven-release/action.yml (7)
13-20: Standardize Version Input Descriptions
Both the "releaseVersion" and "developmentVersion" inputs would benefit from a standardized description style. For instance, use "Release version" and "Next development version with snapshot" for clarity.
54-57: Info: Inline Comment Spacing in Checkout and Setup Steps
The inline comment spacing in the "Checkout code" and "Set up JDK" steps is managed by Renovate bot. No manual changes are necessary.
83-85: Verify: Artifact Name Calculation via hashFiles
The artifact name is generated using the expression:
hashFiles(format('./{0}/pom.xml', inputs.app-path))
Please verify that this usage of the hashFiles function along with format produces the expected file path and hash value for the artifact.
86-91: Duplicate: Upload Artifact Step YAML Formatting
The "Upload Artifact" step shows inline comment spacing issues and is missing a newline at the end of the file. As noted in previous reviews, these formatting details are managed by Renovate bot. No manual changes are necessary if the bot is handling these adjustments.
78-81:⚠️ Potential issueCritical: Environment Variable Mapping Error
Within the Maven Release Step, the environment variable "SIGN_KEY_PASS" is incorrectly set using the "GPG_PRIVATE_KEY" input. It should use the "SIGN_KEY_PASS" input instead.
Suggested change:- SIGN_KEY_PASS: ${{ inputs.GPG_PRIVATE_KEY }} + SIGN_KEY_PASS: ${{ inputs.SIGN_KEY_PASS }}Likely invalid or redundant comment.
77-77: 🛠️ Refactor suggestion
⚠️ Potential issueCritical: Incorrect Relative Path in Maven Release Command
Similarly, the Maven release command uses ".${{inputs.app-path}}/pom.xml". Update this to use "./${{ inputs.app-path}}/pom.xml" for proper relative path resolution.
Suggested change:- mvn release:prepare release:perform -f .${{inputs.app-path}}/pom.xml -B -DreleaseVersion=${{ inputs.releaseVersion }} -DdevelopmentVersion=${{ inputs.developmentVersion }} -Darguments="-Dmaven.deploy.skip=${{ inputs.skipDeployment }}" + mvn release:prepare release:perform -f "./${{ inputs.app-path}}/pom.xml" -B -DreleaseVersion=${{ inputs.releaseVersion }} -DdevelopmentVersion=${{ inputs.developmentVersion }} -Darguments="-Dmaven.deploy.skip=${{ inputs.skipDeployment }}"Likely invalid or redundant comment.
74-76: 🛠️ Refactor suggestion
⚠️ Potential issueCritical: Incorrect Relative Path in Maven Help Command
The Maven help command uses a relative path flag "-f .${{inputs.app-path}}/pom.xml". This format may result in an incorrect path resolution. It is recommended to update it to use a leading "./" as in the JDK setup step.
Suggested change:- MVN_ARTIFACT_ID=$(mvn -f .${{inputs.app-path}}/pom.xml org.apache.maven.plugins:maven-help-plugin:3.2.0:evaluate -Dexpression=project.artifactId -q -DforceStdout) + MVN_ARTIFACT_ID=$(mvn -f "./${{ inputs.app-path}}/pom.xml" org.apache.maven.plugins:maven-help-plugin:3.2.0:evaluate -Dexpression=project.artifactId -q -DforceStdout)Likely invalid or redundant comment.
|
@ejcsid ich würde noch irgendwie den Ordner wechseln. weil sonst kann man die Templates verwechseln mit den tatsächlichen Workflows für das Repo |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/actions/action-npm-release/action.yml(1 hunks)
🧰 Additional context used
📓 Learnings (1)
.github/actions/action-npm-release/action.yml (2)
Learnt from: ejcsid
PR: it-at-m/lhm_actions#8
File: .github/actions/action-npm-release/action.yml:42-43
Timestamp: 2025-02-07T09:48:40.619Z
Learning: Comments and version references in YAML files that are managed by Renovate bot should not be modified for style/formatting as they are automatically maintained.
Learnt from: ejcsid
PR: it-at-m/lhm_actions#8
File: .github/actions/action-npm-release/action.yml:40-41
Timestamp: 2025-02-07T09:48:22.922Z
Learning: Inline version comments (e.g., `# v4.2.2`) after Git commit hashes in GitHub Actions workflow files are typically added by Renovate bot and should not be modified for spacing, as they follow Renovate's standardized format.
🪛 YAMLlint (1.35.1)
.github/actions/action-npm-release/action.yml
[error] 29-29: trailing spaces
(trailing-spaces)
[error] 33-33: too many spaces after colon
(colons)
[warning] 41-41: too few spaces before comment
(comments)
[warning] 43-43: too few spaces before comment
(comments)
🔇 Additional comments (14)
.github/actions/action-npm-release/action.yml (14)
1-2: Action Name Definition is Clear
The file starts with a clear and appropriate action name ("Npm Release") that immediately indicates its purpose.
3-8: "node-version" Input Defined Correctly
The "node-version" input is well defined with a default value, type, and description.
9-12: "app-path" Input is Properly Configured
This input correctly ensures that the directory containing package.json is specified.
13-20: "releaseVersion" Input Offers Clear SemVer Options
The choice input for incrementing the version (patch, minor, major) is both clearly described and properly required.
21-24: "skip-deployment" Input is Appropriately Defaulted
The boolean flag with a default of true is set up correctly to control the deployment step.
25-28: "npm-token" Input is Securely Defined
The required npm token input is clearly specified. Ensure this value is managed via secure repository secrets.
39-41: Checkout Repository Step – Renovate Comment Preservation
The checkout step uses a fixed commit hash along with an inline version comment. As these inline comments are typically maintained by Renovate bot, no spacing modifications are necessary here.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 41-41: too few spaces before comment
(comments)
42-43: Setup Node.js Step – Preserve Renovate Inline Comment Format
Similar to the checkout step, the inline comment on the Node.js setup action is auto-generated by Renovate. Hence, spacing changes are not recommended.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 43-43: too few spaces before comment
(comments)
44-48: Node.js Setup "with" Block is Well Configured
The parameters (node-version, registry URL, cache settings, etc.) are properly set, ensuring that the Node.js environment is correctly initialized.
62-65: Verify Action Reference for Build Step
The workflow calls an action using the identifier "it-at-m/.github/.github/actions/action-npm-build@main". The repeated ".github" directory segment appears atypical. Please verify that this repository path is intentional and correct.
66-70: Conditional Deployment Step is Configured Correctly
This step correctly uses a conditional ("if:") to determine whether to publish the npm package. The use of the --provenance flag and public access settings for publishing is appropriate.
70-71: Environment Variable for NODE_AUTH_TOKEN is Set Appropriately
The NODE_AUTH_TOKEN is correctly mapped from the input. The inline comment is clear, and the spacing meets the necessary guidelines.
30-36: 🧹 Nitpick (assertive)Outputs Definition Needs Minor Formatting Adjustment
The outputs for ARTIFACT_NAME and ARTIFACT_VERSION are correctly declared; however, line 33 has extra spaces after the colon. Aligning this with YAML style guidelines will ensure passing lint checks.- value: ${{ steps.node.outputs.artifact-name }} + value: ${{ steps.node.outputs.artifact-name }}Likely invalid or redundant comment.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 33-33: too many spaces after colon
(colons)
29-29: 🧹 Nitpick (assertive)Remove Trailing Spaces
Trailing whitespace is detected on this line. Removing extraneous spaces will help in maintaining YAML formatting consistency.- +Likely invalid or redundant comment.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 29-29: trailing spaces
(trailing-spaces)
| - id: node-release | ||
| name: Bump version and create git tag | ||
| working-directory: ./${{inputs.app-path}} | ||
| run: | | ||
| NEW_VERSION=$(npm version ${{inputs.releaseVersion}}) || exit 1 | ||
| echo "VERSION=$NEW_VERSION" >> "$GITHUB_OUTPUT" | ||
| git config --global user.email "[email protected]" | ||
| git config --global user.name "GitHub Actions" | ||
| git add package.json package-lock.json | ||
| git commit -m "Bump version to ${NEW_VERSION}" || exit 1 | ||
| git tag "${NEW_VERSION}" || exit 1 | ||
| git push && git push --tags || exit 1 | ||
| shell: bash |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Bump Version and Git Tag Step – Consider Streamlining Error Handling
The shell script correctly bumps the version, commits the changes, tags the release, and pushes to the repository. For improved clarity and to reduce repetitive "|| exit 1" checks, consider introducing a "set -e" at the start of the script. This will automatically abort on any error and clean up the command logic.
-run: |
- NEW_VERSION=$(npm version ${{inputs.releaseVersion}}) || exit 1
- echo "VERSION=$NEW_VERSION" >> "$GITHUB_OUTPUT"
- git config --global user.email "[email protected]"
- git config --global user.name "GitHub Actions"
- git add package.json package-lock.json
- git commit -m "Bump version to ${NEW_VERSION}" || exit 1
- git tag "${NEW_VERSION}" || exit 1
- git push && git push --tags || exit 1
+run: |
+ set -e
+ NEW_VERSION=$(npm version ${{inputs.releaseVersion}})
+ echo "VERSION=$NEW_VERSION" >> "$GITHUB_OUTPUT"
+ git config --global user.email "[email protected]"
+ git config --global user.name "GitHub Actions"
+ git add package.json package-lock.json
+ git commit -m "Bump version to ${NEW_VERSION}"
+ git tag "${NEW_VERSION}"
+ git push && git push --tags📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - id: node-release | |
| name: Bump version and create git tag | |
| working-directory: ./${{inputs.app-path}} | |
| run: | | |
| NEW_VERSION=$(npm version ${{inputs.releaseVersion}}) || exit 1 | |
| echo "VERSION=$NEW_VERSION" >> "$GITHUB_OUTPUT" | |
| git config --global user.email "[email protected]" | |
| git config --global user.name "GitHub Actions" | |
| git add package.json package-lock.json | |
| git commit -m "Bump version to ${NEW_VERSION}" || exit 1 | |
| git tag "${NEW_VERSION}" || exit 1 | |
| git push && git push --tags || exit 1 | |
| shell: bash | |
| - id: node-release | |
| name: Bump version and create git tag | |
| working-directory: ./${{inputs.app-path}} | |
| run: | | |
| set -e | |
| NEW_VERSION=$(npm version ${{inputs.releaseVersion}}) | |
| echo "VERSION=$NEW_VERSION" >> "$GITHUB_OUTPUT" | |
| git config --global user.email "[email protected]" | |
| git config --global user.name "GitHub Actions" | |
| git add package.json package-lock.json | |
| git commit -m "Bump version to ${NEW_VERSION}" | |
| git tag "${NEW_VERSION}" | |
| git push && git push --tags | |
| shell: bash |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/actions/action-npm-release/action.yml(1 hunks)
🧰 Additional context used
📓 Learnings (1)
.github/actions/action-npm-release/action.yml (2)
Learnt from: ejcsid
PR: it-at-m/lhm_actions#8
File: .github/actions/action-npm-release/action.yml:42-43
Timestamp: 2025-02-07T09:48:40.619Z
Learning: Comments and version references in YAML files that are managed by Renovate bot should not be modified for style/formatting as they are automatically maintained.
Learnt from: ejcsid
PR: it-at-m/lhm_actions#8
File: .github/actions/action-npm-release/action.yml:40-41
Timestamp: 2025-02-07T09:48:22.922Z
Learning: Inline version comments (e.g., `# v4.2.2`) after Git commit hashes in GitHub Actions workflow files are typically added by Renovate bot and should not be modified for spacing, as they follow Renovate's standardized format.
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Lint
- GitHub Check: Lint
🔇 Additional comments (6)
.github/actions/action-npm-release/action.yml (6)
1-28: Inputs Definition is Clear and Concise
The inputs section is well-defined with proper types, defaults, and descriptions. All required parameters are clearly specified and indented consistently.
39-40: Checkout Step Verification
The checkout step correctly uses the Renovate-managed commit hash and inline version comment. No changes are required here.
41-47: Node.js Setup Step is Good
The Node.js setup step is implemented properly with all the necessary parameters. The inline version comment is maintained as expected.
61-64: Verify External Action Reference
The step referencing the npm build action uses the string "it-at-m/.github/.github/actions/action-npm-build@main." The double “.github” segment is unusual; please confirm that this is intentional and correctly points to the desired action location.
65-70: 🧹 Nitpick (assertive)Improve Inline Comment Spacing in Environment Variable
For enhanced readability, consider adding an extra space before the inline comment in the environment block. For example, modifying:- NODE_AUTH_TOKEN: ${{ inputs.npm-token }} # Centralized token in it-at-m GitHub organization + NODE_AUTH_TOKEN: ${{ inputs.npm-token }} # Centralized token in it-at-m GitHub organizationThis small change improves clarity without affecting functionality.
Likely invalid or redundant comment.
48-60: 🧹 Nitpick (assertive)Improve Error Handling in Version Bump Step
To simplify error handling and reduce repetitive “|| exit 1” checks, consider adding a “set -e” at the beginning of the run block. This will automatically abort the script on any failure.Apply the following diff for clarity:
- run: | - NEW_VERSION=$(npm version ${{inputs.releaseVersion}}) || exit 1 - echo "VERSION=$NEW_VERSION" >> "$GITHUB_OUTPUT" - git config --global user.email "[email protected]" - git config --global user.name "GitHub Actions" - git add package.json package-lock.json - git commit -m "Bump version to ${NEW_VERSION}" || exit 1 - git tag "${NEW_VERSION}" || exit 1 - git push && git push --tags || exit 1 + run: | + set -e + NEW_VERSION=$(npm version ${{inputs.releaseVersion}}) + echo "VERSION=$NEW_VERSION" >> "$GITHUB_OUTPUT" + git config --global user.email "[email protected]" + git config --global user.name "GitHub Actions" + git add package.json package-lock.json + git commit -m "Bump version to ${NEW_VERSION}" + git tag "${NEW_VERSION}" + git push && git push --tagsLikely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
action-templates/actions/action-deploy-docs/action.yml (1)
13-22: Step Definition & Conditional Deployment.
The runs section’s step to deploy to GitHub Pages is correctly set up using the deploy-pages action. One suggestion: the conditional syntax on line 18
if: (github.ref_name == inputs.deploy-branch)
could be made more idiomatic by using an expression with ${{ … }}. For example:
if: ${{ github.ref_name == inputs.deploy-branch }}
This would align with common practices in GitHub Actions and improve readability.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (10)
action-templates/actions/action-build-docs/action.yml(1 hunks)action-templates/actions/action-build-image/action.yml(1 hunks)action-templates/actions/action-checkout/action.yml(1 hunks)action-templates/actions/action-codeql/action.yml(1 hunks)action-templates/actions/action-create-github-release/action.yml(1 hunks)action-templates/actions/action-deploy-docs/action.yml(1 hunks)action-templates/actions/action-maven-build/action.yml(1 hunks)action-templates/actions/action-maven-release/action.yml(1 hunks)action-templates/actions/action-npm-build/action.yml(1 hunks)action-templates/actions/action-npm-release/action.yml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Lint
- GitHub Check: Lint
🔇 Additional comments (37)
action-templates/actions/action-checkout/action.yml (2)
1-2: Action Metadata is Clear.
The name and description succinctly convey that this composite action is a lightweight wrapper around the standard checkout.
4-8: Composite Steps and Version Pinning.
The composite runs section is well structured. Pinning the checkout action to commit 11bd71901bbe5b1630ceea73d27597364c9af683 (v4.2.2) ensures reproducibility. Just verify that pinning to a commit is intentional versus using a version tag.action-templates/actions/action-deploy-docs/action.yml (1)
1-12: Input Parameter Definitions.
The inputs for artifact_name and deploy-branch are clearly declared with appropriate defaults and descriptions. This clarity helps downstream workflows match expected input/output behaviors.action-templates/actions/action-create-github-release/action.yml (2)
1-15: Release Action Input Declaration.
The inputs for artifact-name, tag-name, and artifact-path are explicitly required and clearly described. This thorough declaration is beneficial for predictable behavior in release creation.
16-33: Sequential Steps for Release Creation.
The composite action’s steps are well organized: first downloading the artifact using a pinned version of download-artifact and then creating the GitHub Release with softprops/action-gh-release. The version pinning is consistent and the mapping of inputs is clear.action-templates/actions/action-maven-build/action.yml (3)
13-16: Output Declaration.
The output artifact-name is properly set using the output from the “artifact-name” step. Ensure that the echo-based assignment in step 32 produces the expected format for downstream consumption.
17-41: Composite Action Steps for Build and Artifact Upload.
- The checkout and JDK setup steps are correctly configured with proper version pinning.
- In the “Set up JDK” step (lines 21–27), the cache-dependency-path uses "./${{inputs.app-path}}/pom.xml". If app-path is intended to be a directory, a more descriptive input name (e.g., pom-dir) might improve clarity.
- The build command on line 29 correctly references the pom.xml file, but note that using ./${{inputs.app-path}}/pom.xml assumes that app-path points to a directory—confirm this usage.
- The artifact-name calculation in line 32 uses hashFiles with a format function; please verify that this expression is supported within a composite action.
Overall, the step sequence is logical, but please double-check the semantics of the app-path input and its use in path formatting.
3-12: 🧹 Nitpick (assertive)Input Parameters for Maven Build.
The inputs (java-version and app-path) are defined clearly, although the description for app-path could be rephrased to indicate that it is the directory containing the pom.xml (if that is the case) rather than a full path to the file. Clarification here will prevent potential misuse.action-templates/actions/action-build-docs/action.yml (2)
4-24: Documentation Build Input Configuration.
The inputs for docs-path, node-version, build-cmd, and dist-path are clearly defined with sensible defaults and helpful descriptions. One minor note: ensure that the default node-version ("22") is fully compatible with VitePress and your project's requirements.
26-54: Step-by-Step Docs Build Process.
The composite action steps are logically ordered: starting with checkout, setting up Node with caching, configuring GitHub Pages, installing dependencies, linting, building, and finally uploading the output artifact. Each step is pinned to a specific action version, which is good for stability.
A minor nitpick: there are extra spaces in the npm commands (e.g., between ./${{inputs.docs-path }} and the subsequent arguments) that could be standardized for consistency, though these do not affect execution.[refactor_suggestion_nitpick]
action-templates/actions/action-npm-build/action.yml (4)
1-7: Initialization and Metadata Definition:
The action’s name and the initial node-version input are clearly defined with an appropriate default and description.
8-19: Input Parameters for App Path and Flags:
The inputs for app-path, run-lint, and run-test are clearly specified. Using string values ("true") for boolean-like flags is acceptable in composite actions where comparisons (e.g. if: ${{ inputs.run-lint == 'true' }}) are done using strings.
20-23: Output Definition for Artifact Name:
The output artifact-name is set properly by referencing the output of the corresponding step. This makes the action’s outputs predictable and easy to consume in downstream workflows.
24-57: Composite Steps Implementation:
The composite steps are well-organized: checking out the repository, setting up Node.js (including caching based on the package-lock.json in the specified app-path), installing dependencies, and conditionally running lint, test, and build commands. The artifact name is then computed and used for uploading artifacts.action-templates/actions/action-build-image/action.yml (3)
1-3: Action Metadata:
The action is clearly named "Build Docker Image" with an appropriate description that tells users its purpose.
4-33: Input Parameter Consistency:
All required inputs (registry details, image-tags, image-labels, build path, and artifact-name) are defined clearly with useful defaults and descriptions. The multi-line defaults (for image-tags and image-labels) are a nice touch—just verify that the consumers of these values handle them correctly.
35-65: Composite Steps for Docker Build and Push:
The sequence of steps—from checking out code and downloading the artifact to logging into the Docker registry, extracting image metadata, and finally building and pushing the image—follows best practices. The usage of fixed commit hashes for actions (e.g. checkout, login) improves reproducibility.action-templates/actions/action-npm-release/action.yml (10)
1-8: Action Metadata and Node Version Input:
The action’s name and node-version input are well-defined with a clear default and type specification.
9-12: Application Path Input:
The specification of app-path (pointing to the location of package.json) is clear and makes the action easy to use.
13-20: Version Increment Input:
Defining releaseVersion as a choice (patch, minor, major) ensures only valid semantic version increments are used.
21-24: Deployment Toggle Input:
The skip-deployment parameter is straightforward and correctly defaults to true to prevent deployment unless explicitly overridden.
25-28: Authentication Token Input:
The required npm-token is essential for publishing and is properly highlighted.
29-35: Output Configuration:
Outputs ARTIFACT_NAME and ARTIFACT_VERSION are correctly mapped from the designated steps. Make sure that the actions producing these outputs indeed set them as expected.
36-47: Repository Checkout and Node.js Setup:
The checkout and Node.js setup steps are implemented cleanly, with caching configured via the package-lock.json file located using app-path.
48-60: Version Bump and Git Tag Creation:
The script that bumps the version and creates a git tag is well-structured. Usingexit 1on failure is acceptable; consider adding more robust logging if troubleshooting becomes necessary.
61-65: Delegated Npm Build Execution:
Delegating the build to the npm-build action via the 'node' step promotes DRY principles. Please double-check that the repository reference (it-at-m/.github/.github/actions/action-npm-build@main) is intentional.
66-70: Conditional Deployment Step:
The conditional deployment using npm publish is written correctly, with proper environment variable usage for authentication.action-templates/actions/action-codeql/action.yml (7)
1-3: Action Metadata for CodeQL:
The action name and description clearly communicate its function—to perform CodeQL scans with configurable language, build mode, and query settings.
4-9: CodeQL Language Input:
The mandatory codeql-language input is well-documented and includes a helpful external reference for further details.
10-13: CodeQL Build Mode Input:
The codeql-buildmode input is optional with a sensible default, ensuring flexibility based on the project’s requirements.
14-18: CodeQL Query Input:
Defining codeql-query with a default value streamlines the scanning process. The description and default are in line with best practices.
19-22: Java Version Input for Autobuild:
The java-version input, needed when using an autobuild for java-kotlin projects, is clearly defined. Ensure that the default ("21") matches your project’s compatibility requirements.
23-26: Path Input:
The path parameter specifies the target directory for scanning and defaults to the current directory, which is appropriate for most setups.
27-55: Composite Steps for CodeQL Analysis:
The composite steps cover all necessary parts: repository checkout, conditional JDK setup for java-kotlin with autobuild, CodeQL initialization, conditional autobuild, and finally, the analysis step. This structured approach ensures flexibility across different project types.action-templates/actions/action-maven-release/action.yml (3)
41-49: Output Configuration:
The outputs (MVN_ARTIFACT_ID and artifact-name) are appropriately defined and correctly derive their values from downstream steps.
50-67: JDK Setup for Maven Release:
The step to set up the JDK using the provided parameters (including Maven caching and deployment credentials) is well-configured. The mapping for gpg-private-key and gpg-passphrase correctly uses the inputs, ensuring secure release management.
83-92: Artifact Handling:
The steps for computing the artifact name (via a hash of the pom.xml) and uploading the artifact (with a specified retention period) are consistent with the patterns used in the other actions. Verify that the hashFiles function with the given format string functions as expected in your environment.
| name: Maven Release | ||
|
|
||
| inputs: | ||
| java-version: | ||
| required: false | ||
| default: 21 | ||
| type: string | ||
| description: configure the java version | ||
| app-path: | ||
| required: true | ||
| type: string | ||
| description: path where the pom.xml is | ||
| releaseVersion: | ||
| required: true | ||
| type: string | ||
| description: version which will be released | ||
| developmentVersion: | ||
| required: true | ||
| type: string | ||
| description: next version with snapshot | ||
| skipDeployment: | ||
| default: true | ||
| type: boolean | ||
| description: skip deployment to maven central | ||
| SIGN_KEY_PASS: | ||
| required: true | ||
| type: string | ||
| description: env variable for GPG private key passphrase | ||
| CENTRAL_USERNAME: | ||
| required: true | ||
| type: string | ||
| description: env variable for username in deploy | ||
| CENTRAL_PASSWORD: | ||
| required: true | ||
| type: string | ||
| description: env variable for token in deploy | ||
| GPG_PRIVATE_KEY: | ||
| required: true | ||
| type: string | ||
| description: Value of the GPG private key to import |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Input Parameter Definitions:
The Maven Release action includes comprehensive input parameters (java-version, app-path, releaseVersion, developmentVersion, skipDeployment, SIGN_KEY_PASS, CENTRAL_USERNAME, CENTRAL_PASSWORD, and GPG_PRIVATE_KEY). One minor suggestion: quote the default value for java-version (e.g., "21") to ensure it is treated as a string, consistent with the input type.
|
@hupling Deine Anmerkungen #8 (comment) und #8 (comment) habe ich umgesetzt |
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
action-templates/actions/action-maven-release/action.yml (1)
4-8: 🧹 Nitpick (assertive)Quote default value for java-version.
The default value for the string input "java-version" is unquoted (line 6). For type consistency and to avoid any implicit type conversion issues, please quote it (e.g., "21").Proposed diff:
- default: 21 + default: "21"
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
action-templates/actions/action-maven-release/action.yml(1 hunks)
🔇 Additional comments (1)
action-templates/actions/action-maven-release/action.yml (1)
72-77: 🧹 Nitpick (assertive)Fix file path inconsistency in Maven command.
The Maven command at line 74 uses a file path starting with ".${{inputs.app-path}}/pom.xml" which omits a slash after the dot. It is more consistent and less error-prone to use the same "./${{ inputs.app-path}}/pom.xml" notation as seen later in the file (line 77).Proposed diff:
- MVN_ARTIFACT_ID=$(mvn -f .${{inputs.app-path}}/pom.xml org.apache.maven.plugins:maven-help-plugin:3.2.0:evaluate -Dexpression=project.artifactId -q -DforceStdout) + MVN_ARTIFACT_ID=$(mvn -f ./${{inputs.app-path}}/pom.xml org.apache.maven.plugins:maven-help-plugin:3.2.0:evaluate -Dexpression=project.artifactId -q -DforceStdout)
|
@hupling kannst du bitte nochmal reviewen. Die restlichen Code Rabbit Kommentare würde ich ignorieren. |
|
🎉 This PR is included in version 1.0.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Description
Short description or comments
Reference
Issues #.github/issues/110
Summary by CodeRabbit