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

Support automatically merging PRs that don't affect target clusters #6

Merged
merged 3 commits into from
May 15, 2024

Conversation

Oded-B
Copy link
Collaborator

@Oded-B Oded-B commented May 15, 2024

Description

Support automaticallyh merging PRs that don't affect target clusters - those usually happen when you change some component configuration that affect only some of the environments.
We still want to merge these to avoid environment drift.

Type of Change

  • Bug Fix
  • New Feature
  • Breaking Change
  • Refactor
  • Documentation
  • Other (please describe)

Checklist

  • I have read the contributing guidelines
  • Existing issues have been referenced (where applicable)
  • I have verified this change is not present in other open pull requests
  • Functionality is documented
  • All code style checks pass
  • New code contribution is covered by automated tests
  • All new and existing tests pass

@Oded-B Oded-B marked this pull request as ready for review May 15, 2024 09:27
docs/installation.md Outdated Show resolved Hide resolved
Oded-B and others added 2 commits May 15, 2024 11:38
Co-authored-by: Sunil Aggarwal <sunil.aggarwal@commercetools.com>
Co-authored-by: Sunil Aggarwal <sunil.aggarwal@commercetools.com>
@Oded-B Oded-B changed the title Support automaticallyh merging PRs that don't affect target clusters Support automatically merging PRs that don't affect target clusters May 15, 2024
ghPrClientDetails.PrLogger.Infof("Auto-merging (no diff) PR %d", *eventPayload.PullRequest.Number)
err := MergePr(ghPrClientDetails, eventPayload.PullRequest.Number)
if err != nil {
prHandleError = err

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a thought but non blocking for this, I see this is following convention below but would be shadowed if errors happens there. Could potentially use errors.Join or refactor to avoid it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

errors.Join == mind blown :)
I'll merge as is because I do log the errors so they are not completely lost but yeah, keeping them all is definitely better

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:0 I didn't even know about errors.Join

TechTime on error wrapping would definitely be killer. ErrorWrapping isn't something I've really picked up. I do love being able to use errors.Is for error pathing.

Copy link

@hnnsgstfssn hnnsgstfssn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Oded-B Oded-B merged commit 7f33a8b into main May 15, 2024
5 checks passed
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.

4 participants