Merging release into master and dev

[provJoshMieczkowski]

Is there a way to merge the changes from release to master and dev vs release -> master -> dev. The issue being if there is a merge conflict, we don't want to update with dev code that isn't ready to be in master.

[Logerfo]

tl;dr: I'm not sure if I understood the reason why you need this. Anyway, I don't think its possible right now. Maybe in a future version, but the design is still uncertain.

---

First of all, why do you need this? Can you clarify this merge conflict situation? Perhaps with an example? Please note that merge conflicts will block the PR and will not auto-merge, even with the config auto-merge off.

Anyway, one possibility would be to have multiple targets. This would require the master config attribute to be split into target master (coming from the release branch) and source master (to the dev branch). This target attribute would also need to accept an array in order to support multiple targets. Something like this:

release: release # default
master-target: [master, dev]
master-source: master # default for the current `master` config
dev: dev # default

It's worth noting that some other changes regarding this configuration was also requested. See #18, #9 and #6. Perhaps a solution could be formulated to fix all those four requests.
Another way to solve your problem would be to have zero (null) source and targets. Then you could have three steps in the same action. Something like this:

steps:
- uses: Logerfo/gitflow-action@0.0.4 # from master to dev
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    release: null
- uses: Logerfo/gitflow-action@0.0.4 # from release to master
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    dev: null
- uses: Logerfo/gitflow-action@0.0.4 # from release to dev
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    master: dev
    dev: null

I think the same behavior might be achievable with only two steps, but couldn't think of a solution right now.
Either way, both possible solutions would be stuck with the following problem: merging from release to master would trigger to action to merge from master to dev, which already happens today and it's what you're fighting against. Even when supporting merging from release to master directly, this would happen, thus you'd have two merges from release to dev, one of them directly and the other one passing through master in the middle of the way.
To solve this, the action would need to ignore merges coming from itself, which is harder to design.
Nevertheless, I'm open to ideas and pull requests.

[provJoshMieczkowski]

Let me see if I can rephrase.
Today: release/* merges into master which then creates a PR to merge master to dev
Request: release/* merges into master and release/* merges into dev

Why: Dev is being work on and changes are being made, maybe some hotfix or something is going with master. Whatever the reason, trying to merge master into dev fails because there is a merge conflict. To resolve this merge conflict, you need to pull dev into master which now create a dirty copy of master and no longer reflects what is actually in release.

tl;dr: Have release/* create a PR for dev to handle merge conflicts instead of having master pull in dev changes.

[Logerfo]

But what would you do when a bugfix gets merged into master? A PR merging from master to dev is also opened and the merge conflict will also exist. How do you currently solve this case?