Skip to content
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

Add continue-on-error to publish workflow #944

Merged
merged 7 commits into from
Jan 11, 2024

Conversation

goastler
Copy link
Member

No description provided.

@goastler goastler enabled auto-merge (squash) January 11, 2024 12:14
Copy link

Pull Request Report

Hey there! 👋 Here's the report for the pull request:

Changes

  1. Refactored the publish workflow into granular version checks.
  2. Fixed the references to the next version variable.
  3. Performed linting.
  4. Added echo statements for publishing bumps.

Suggestions

  • Line 188: Consider using a more descriptive message for the echo statement. For example, instead of "github bump required," you could say "GitHub bump is required."
  • Line 192: Similarly, you can improve the echo statement by saying "npm bump is required" instead of "npm bump required."
  • Line 196: The echo statement can be more specific. Instead of "docker js_server bump required," you can say "Docker js_server bump is required."
  • Line 200: The echo statement can be enhanced by saying "docker provider bump is required" instead of "docker provider bump required."

Bugs

No bugs were found in the code.

Improvements

  • Line 282: Consider adding the continue-on-error: true option for the "Github release" step to handle errors gracefully.
  • Line 290: Similarly, you can add continue-on-error: true for the "Npm release" step to handle errors without stopping the workflow.
  • Line 305: The "Docker js_server release" step can benefit from continue-on-error: true to handle errors smoothly.
  • Line 327: For the "Build and Push the Provider Bundle" step, it would be helpful to add continue-on-error: true to handle errors gracefully.

Rating

I would rate the code a 7 out of 10 based on the following criteria:

  • Readability: The code is generally readable, but some improvements can be made in terms of variable naming and comments.
  • Performance: The code seems to be efficient and doesn't have any obvious performance issues.
  • Security: The code doesn't raise any immediate security concerns, but it's always good to conduct a thorough security review.

That's it for the report! Let me know if you need any further assistance. 😄

@goastler goastler merged commit 86fe25c into main Jan 11, 2024
5 checks passed
@goastler goastler deleted the improve-publish-version-checks branch January 11, 2024 12:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants