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

Feature/remote branch #3208

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ianbarrere
Copy link

Pre-Request Checklist

  • Passes rubocop code analysis (try rubocop --auto-correct)
  • Tests added or adapted (try rake test)
  • Changes are reflected in the documentation
  • User-visible changes appended to CHANGELOG.md

Description

My organization has strict branch naming rules in our GitLab instance, and so I could not create a branch called "master". This adds functionality to specify a remote branch name with "remote_branch" key under githubrepo hook. The default is master, but can be overridden with this.

It also adds a bit more complete logging for pushes. It was failing silently for me before so it took a long time to track down the issue. Now it should be quite clear if the push fails or succeeds.

I'm not at all a ruby developer either, I did my best to follow best practices but feel free to let me know if something could be improved.

Background

To document my process in case somebody needs to do something similar...

I was also trying to add a .gitlab-ci.yml file to define pipeline steps for our GitLab repo. This file was getting overwritten by Oxidized when it would run. What I needed to do was clone the devices.git repo from Oxidized locally, add the .gitlab-ci.yml file to that repo, push to origin, then copy the .git/index file from the working directory over to devices.git/index. This allowed Oxidized to know where it was, I suppose, and subsequent pushes worked and preserved the changes made to the repo outside of the standard Oxidized run.

You can add a key to the remote repo called "remote_branch" which
will push changes to the branch given. This is done by creating (or
reusing) a ref and pushing that ref to remote instead of hard-coding
master.

(Also updated tests to pass in remote branch name)
Pushes could fail silently before, this checks for a non {} response
from remote (indicating that something went wrong) and logs an
alert if gotten. Otherwise it logs a success message.
@ianbarrere
Copy link
Author

@robertcheramy I saw that last time I submitted this you were able to run a test via the pipeline (which failed, which I think I have fixed here). I couldn't get rake working properly locally, so I was wondering if I could initiate the same pipeline tests somehow.

@github-actions github-actions bot added the Stale label Aug 24, 2024
@robertcheramy
Copy link
Collaborator

@ianbarrere - have a look at https://github.com/ytti/oxidized/blob/master/CONTRIBUTING.md#create-a-ruby-bundle and the chapters after it. It should help run rubocop localy.

@robertcheramy
Copy link
Collaborator

robertcheramy commented Oct 2, 2024

I've finally found time to make a deep dive into rugged and libgit2, so I can understand this PR.
This all looks very good, I'll have a look at the failing unit tests.

@ianbarrere
Copy link
Author

I've finally found time to make a deep dive into rugged and libgit2, so I can understand this PR. This all looks very good, I'll have a look at the failing unit tests.

Thank you! I still have not managed to fix the tests either, so that would be greatly appreciated.

@robertcheramy
Copy link
Collaborator

While trying to fix the unit tests, I realize that I'm still struggling with the code AND git remotes + references AND rugged AND libgit2 - the last two are not documented in a way that makes it easy for me to understand. That is quite much and I'll need some more time on this 😅

But I already have a question.
I understand from the comment that rugged doesn't give the possibility to link a local and a remote branch with different names. Okay.

fetch_and_merge only fetches "our" (configured) remote branch [main], but as it is not linked to the local branch [master], how can result[:total_deltas] ever be positive?

And one thought: wouldn't it be easier to call the local branch as you like [main] and then sync to the remote using the same name? Migrating the local git to a new branch name could be done manually, or though the remote git and fetch_an_merge (to be tested).

@ianbarrere
Copy link
Author

fetch_and_merge only fetches "our" (configured) remote branch [main], but as it is not linked to the local branch [master], how can result[:total_deltas] ever be positive?

I'm not 100% sure since I can't find much on total_deltas, but my guess is that it's comparing it to HEAD (which is essentially the branch that is currently checked out). The fetch operation just pulls down the specified branch, but it doesn't do anything with it yet, so it hasn't merged it in or checked it out, it has just pulled it down so that it can be inspected.

And one thought: wouldn't it be easier to call the local branch as you like [main] and then sync to the remote using the same name? Migrating the local git to a new branch name could be done manually, or though the remote git and fetch_an_merge (to be tested).

This is a good point. It didn't occur to me as a solution when I was initially working on this, but I think it would work as long as we update the code to at least have the branch name (both remote and local) be variable. I will see if I can write something up to simplify this using the same branch name locally and remote.

@robertcheramy
Copy link
Collaborator

Okay, this works without a code change. oxidized.git is the local git repo of oxidized.

# stop oxidized.
# This is the state before doing something
$ git --git-dir=oxidized.git branch -avv
* master                ad09962 update Group1/MY-SW9L3
  remotes/origin/master ad09962 update Group1/MY-SW9L3
# rename the branch
$ git --git-dir=oxidized.git branch -m master funky_name
# notice that remote still is master
$ git --git-dir=oxidized.git branch -avv
* funky_name            ad09962 update Group1/MY-SW9L3
  remotes/origin/master ad09962 update Group1/MY-SW9L3
# Run oxidized, and stop it again.
# Notice that remote/origin/master have not been updated
$ git --git-dir=oxidized.git branch -avv
* funky_name                c01a518 update Group2/MY-R51
  remotes/origin/funky_name c01a518 update Group2/MY-R51
  remotes/origin/master     ad09962 update Group1/MY-SW9L3
# Login into your remote gitlab, remove the remote master branch
# Now fetch and prune removed branches
$ git --git-dir=oxidized.git fetch -p
From git.example.com:git_repo
 - [deleted]         (none)     -> origin/master
$ git --git-dir=oxidized.git branch -avv
* funky_name                c01a518 update Group2/MY-R51
  remotes/origin/funky_name c01a518 update Group2/MY-R51
# done!

@ianbarrere
Copy link
Author

Wow, nice! So how does that square with the "master" reference in code here I wonder?

@robertcheramy
Copy link
Collaborator

Good point. It doesn't.
In my example I had no merge because it created a new branch remote, so the code line wasn't reached.
This has to be corrected, I will look into it.

@robertcheramy
Copy link
Collaborator

Update - still working on it, I've already got a code working with a custom branch name, I must update the unit tests and the documentation.

robertcheramy added a commit that referenced this pull request Oct 15, 2024
- Addresses issue in PR #3208
- Documents custom branch namename
- Excludes rubocop Metrics/BlockLength for unit tests - they can become
very long...
@robertcheramy
Copy link
Collaborator

Please test commit 34c3e7d if it solves your problem. Renaming the branch is documented in Hooks.md.
If it is works for your Issue, I would close this PR without merging.

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