[PLA-1672] add release action

[zlayine]

Type

enhancement

---

Description

• Enhanced CI/CD workflow by adjusting indentation for better readability.
• Changed the build artifact path to align with project structure.
• Introduced a new release job to automate the release process. This job triggers on push to master, creates a new GitHub release, and uploads the build artifact as a zip file.

---

Changes walkthrough

	Relevant files
Enhancement	deploy.yml Enhancement of CI/CD Pipeline with Release Automation        .github/workflows/deploy.yml Adjusted indentation for pull_request and push triggers. Changed artifact path from dist to public. Added a new release job that creates and uploads a release artifact upon push to master. +42/-9

---

✨ PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[github-actions]

PR Description updated to latest commit (3c14815)

[github-actions]

PR Review

⏱️ Estimated effort to review [1-5]	3, because the PR involves changes to the CI/CD pipeline which requires a careful review of the YAML syntax, understanding of the GitHub Actions used, and ensuring that the new release job works as intended without disrupting existing workflows.
🧪 Relevant tests	No
🔍 Possible issues	Possible Bug: The tag_name and release_name in the Create Release step use ${{ github.ref }}, which will include the full ref path (e.g., refs/heads/master). This might not be the intended format for tags and release names.
	Possible Improvement: The artifact path in the Upload Release Artifact step is hardcoded to ./public/build, but the Archive build artifacts step does not specify archiving the build directory specifically within public.
🔒 Security concerns	No

Code feedback:

---

relevant file	.github/workflows/deploy.yml
suggestion	Consider using a more user-friendly tag and release name format by extracting the version number or using a different strategy for naming. For example, if you're following semantic versioning, you might want to extract the version number from a file or use a date-based versioning scheme. [important]
relevant line	tag_name: ${{ github.ref }}

---

relevant file	.github/workflows/deploy.yml
suggestion	Ensure the asset_path in the Upload Release Artifact step correctly reflects the structure of the archived artifact. If the build directory is not specifically created within public, this step may fail to find the artifact. Consider verifying the artifact structure or adjusting the path accordingly. [important]
relevant line	asset_path: ./public/build

---

---

✨ Review tool usage guide:

---

Overview:
The review tool scans the PR code changes, and generates a PR review which includes several types of feedbacks, such as possible PR issues, security threats and relevant test in the PR. More feedbacks can be added by configuring the tool.

The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.

• When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

• With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

See the review usage page for a comprehensive guide on using this tool.

[github-actions]

PR Code Suggestions

Category	Suggestions
Enhancement	Limit workflow runs to specific branches. Consider specifying branches for the push and pull_request events to limit the workflow runs to specific branches. This can help in avoiding unnecessary workflow runs on branches that don't require this workflow. For example, you might want to run this workflow only on the master branch or on feature branches but not on others. .github/workflows/deploy.yml [3-8] pull_request: + branches: + - master paths-ignore: - '**.md' push: + branches: + - master paths-ignore: - '**.md'
	Improve readability of tag and release names. For the tag_name and release_name fields in the create-release step, directly using github.ref might not yield user-friendly names, as github.ref includes refs/heads/ for branches. Consider using a more readable format or extracting the branch name using expressions if the intention is to use the branch name. .github/workflows/deploy.yml [48-49] -tag_name: ${{ github.ref }} -release_name: Release ${{ github.ref }} +tag_name: ${{ github.ref_name }} +release_name: Release ${{ github.ref_name }}
Best practice	Use the latest or most suitable versions of GitHub Actions. It's recommended to use the latest version of actions such as actions/checkout@v2 and actions/upload-artifact@v2. However, for actions/create-release@v1 and actions/upload-release-asset@v1, consider checking if there are newer versions available or alternatives that are being actively maintained, as using the latest or most suitable version can bring in new features, bug fixes, and improvements in performance and security. .github/workflows/deploy.yml [37-57] - uses: actions/checkout@v2 - uses: actions/upload-artifact@v2 -- uses: actions/create-release@v1 -- uses: actions/upload-release-asset@v1 +- uses: actions/create-release@latest +- uses: actions/upload-release-asset@latest
	Add failure handling for critical workflow steps. Consider adding failure handling for critical steps in the workflow. For example, steps that deploy the application, create releases, or upload artifacts should ideally have error handling or conditional execution to manage failures gracefully. This can be achieved using if conditions or by setting continue-on-error: false explicitly for critical steps to make the failure scenarios clear. .github/workflows/deploy.yml [42-43] - name: Create Release id: create_release uses: actions/create-release@v1 + if: success() + continue-on-error: false
Possible issue	Verify the artifact path and ensure the artifact exists. Ensure that the asset_path in the Upload Release Artifact step points to the correct path of the artifact to be uploaded. If the build process generates artifacts in public/build, make sure that the artifact (build.zip) exists at this location before this step runs. If necessary, add a step to create build.zip from the contents of public/build. .github/workflows/deploy.yml [62-63] -asset_path: ./public/build +# Ensure the build.zip is created from public/build contents before this step +asset_path: ./public/build.zip asset_name: build.zip

---

✨ Improve tool usage guide:

---

Overview:
The improve tool scans the PR code changes, and automatically generates suggestions for improving the PR code. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on a PR.

• When commenting, to edit configurations related to the improve tool (pr_code_suggestions section), use the following template:

/improve --pr_code_suggestions.some_config1=... --pr_code_suggestions.some_config2=...

• With a configuration file, use the following template:

[pr_code_suggestions]
some_config1=...
some_config2=...

See the improve usage page for a comprehensive guide on using this tool.

[leonardocustodio]

To where this is being uploaded? The repo assets itself?