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

Backmerge on feature branches #42

Open
mehdihadeli opened this issue Jan 26, 2023 · 2 comments
Open

Backmerge on feature branches #42

mehdihadeli opened this issue Jan 26, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@mehdihadeli
Copy link

mehdihadeli commented Jan 26, 2023

Hi @saitho,
Is it possible back merge develop branch on feature branches?
Because naming for branches doesn't support regex (like: feat/**), we can't do this now.
For example:

- - '@saithodev/semantic-release-backmerge'
  - branches:
    - from: main
      to: dev
    - from: dev
      to: feat/**
    backmergeStrategy: merge
    mergeMode: ours 
    clearWorkspace: false
@saitho
Copy link
Owner

saitho commented Jan 26, 2023

Hi @mehdihadeli

Backmerging into one feature branch named "feature/my-feature" should work with the current implementation. Merging into multiple branches using RegEx is not possible.
Right now I am hesistant to implement this:

semantic-release itself is not compatible with workflows that require backmerging – moreover they strictly advertise a single branch concept. As GitFlow is a wide-spread concept, this plugin tries to provide basic means to use it anyways, using hooks in semantic-release that were not designed for such actions.

Depending on the state of the branches backmerges may fail, causing the entire semantic-release process to fail, leaving you with a ready release that was not backmerged correctly, red pipeline and possibly steps after the release process that could not run.

Backmerging into multiple branches via a RegEx (e.g. all feature branches; some of them may be weeks or months behind and not merge/rebase properly) may cause such issues that would probably be more annoying than helpful.

I am not completely against it, just thinking about the risks. 😅

@saitho saitho added the enhancement New feature or request label Jan 26, 2023
@mehdihadeli
Copy link
Author

mehdihadeli commented Jan 26, 2023

Yes, I agree. What about using feature branch in merge with -Xours command, it helps out for preserving feature branches changes that are not in develop yet.
About feature/my-feature, should I define all of my feature branches one by one in the config file?
For preventing fail whole of sematnic-release process, maybe it is better we do back merge in a separate GitHub action after running semantic-release. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants