-
Notifications
You must be signed in to change notification settings - Fork 920
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
base: master
Are you sure you want to change the base?
Feature/remote branch #3208
Conversation
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.
@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. |
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. 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). |
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.
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. # 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! |
Wow, nice! So how does that square with the "master" reference in code here I wonder? |
Good point. It doesn't. |
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. |
- Addresses issue in PR #3208 - Documents custom branch namename - Excludes rubocop Metrics/BlockLength for unit tests - they can become very long...
Please test commit 34c3e7d if it solves your problem. Renaming the branch is documented in Hooks.md. |
Pre-Request Checklist
rubocop --auto-correct
)rake test
)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.