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

[v6] No longer switch branches locally and drop create_branch, skip_fetch and skip_checkout options #314

Draft
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

stefanzweifel
Copy link
Owner

@stefanzweifel stefanzweifel commented Dec 20, 2023

This pull request tackles a long standing issue with this action: how the action works with branches internally.

Since forever, the action will switch branches locally, if a branch name is provided through the branch-option.
This leads to a slew of problems, when users write workflows, where the repo is checked out using the default branch (main) but the changes are then pushed to a different branch (example-branch-1) (Example: #301).

This annoyed me for a long time. There's no need to check out the given branch locally. A local branch does not have to align with the remote branch in order to push a commit to said remote branch.
We can target the right target branch in the git-push command.


This PR changes this behaviour by removing the _switch_to_branch function completely.
By removing the function, the action also no longer runs git-fetch.

The test suite of the action has been adjusted accordingly. Some tests have been removed. Some tests have been rewritten, as removing the _switch_to_branch function changed the behaviour of the action in certain cases. See "Breaking Changes" section for details.

As this is a breaking change, this change will be released in an upcoming major release (v6) of this Action.


Why I added the current behaviour of switching branches locally is a mistery to me. I probably wrote the code this way, as I personally always mirror the branch names in my local repository with my remote repository. (I would work on a branch called feature-x and push that to origin/feature-x and not origin/development)

Potential Issues

If a user checks out a repository on it's default branch (main), makes changes to the repo and pushes the changes to remote branch example which already exists on remote and has newer commits, the action will fail to push to remote with an error message like this:

Updates were rejected because the remote contains work that you do
not have locally. This is usually caused by another repository pushing
to the same ref. You may want to first integrate the remote changes
(e.g., 'git pull ...') before pushing again.

The solution here will still be, that the user has to solve these "out-of-sync" issues on their own by adding a git-pull or git-rebase step in their workflows.

Breaking Changes

TBD

Related Issues

TODOs

  • Make tests green again
  • Write UPGRADE.md
  • Document breaking changes
  • Update Docs

@stefanzweifel stefanzweifel self-assigned this Dec 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant