ytti
Feature/remote branch
Pre-Request Checklist
- [x] Passes rubocop code analysis (try
rubocop --auto-correct) - [x] Tests added or adapted (try
rake test) - [x] Changes are reflected in the documentation
- [x] 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.
@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.
@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.
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.
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.
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).
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.
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!
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.
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.
Please test commit 34c3e7d42ec6c05c72c792e60780da0ac062047c 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.