http://coldfusion.com logo
Join Slack
Powered by
Any idea on what is causing this? Just trying to i...
# box-products
d
Any idea on what is causing this? Just trying to install a package that has been used plenty of times before with the same version of commandbox in our container (can recreate locally too). 
Error cloning github repository org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict with files:tests/resources/app/handlers/Main.cfc
b
I feel like if seen this before
Can you ensure the old package uninstalled fully?
d
Like, blow away the folder and then try again?
b
Yeah
d
I blew away the folder and then even the entire modules directory. It always fails on 
cfcollection
with that same error.
The container is a different version than locally (commandbox 5.0.1 and cfcollection 2.8.0) but I can reproduce the same error locally with commandbox 5.4.2 and cfcollection 2.10.2.
b
I wonder if it's related to the new jgit version in CommandBox 5.5.0. I updated the jar.
Oh wait, Only on my phone and didn't read that right. You said you can recursive reproduce on 5.4.2
Seems the issue is with cfcollection perhaps
@elpete have you seen this?
e
No. I also haven't touched that repo in years.
b
@danmurphy I got a chance to try this locally and it seems to be working ok for me
Copy code
❯ install cfcollection@2.8.0 --verbose
 √ | Installing package [forgebox:cfcollection@2.8.0]
   |---------------------------------------------------------------
   | Verifying package 'cfcollection' in forgebox, please wait...
   | Installing version [2.8.0].
   | Verified entry in forgebox: 'cfcollection'
   | Deferring to [github] endpoint for forgebox entry [cfcollection]...
   | Using branch [v2.8.0]
   | Cloning Git URL [<https://github.com/elpete/cfcollection.git>]
   | remote: Enumerating objects
   | remote: Counting objects (45)
   | remote: Compressing objects (43)
   | Receiving objects (17931)
   | Resolving deltas (3814)
   | Checking out files (74)
   | Available branches are refs/heads/master,refs/remotes/origin/dependabot/npm_and_yarn/is-my-json-valid-2.20.0,refs/remotes/origin/dependabot/npm_and_yarn/macaddress-0.2.9,refs/remotes/origin/dep
   | endabot/npm_and_yarn/marked-0.3.19,refs/remotes/origin/dependabot/npm_and_yarn/sshpk-1.16.1,refs/remotes/origin/dependabot/npm_and_yarn/stringstream-0.0.6,refs/remotes/origin/development,refs/r
   | emotes/origin/master,refs/remotes/origin/transducers
   | Storing download in artifact cache...
   | Done.
   | C:\sandbox\/box.json updated with dependency.
   | Installing to: C:\sandbox\/modules/cfcollection
   | -> 11 File(s) Installed
   | -> 17 File(s) ignored
   | Eureka, 'cfcollection@2.8.0' has been installed!
I am using CommandBox 5.5.0 (with the workaround in place for github cloning to work)
d
Thanks for following up @bdw429s . So that might be what we have to do then. Our current dockerfile is running a previous version of commandbox (5.x something). I wasn't aware there was a fix for GitHub cloning. What was the issue exactly?
b
Check the thread from today in #box-products
👍 1
The 5.5 release had a regression that crept in days before I released that managed to screw up jGit
d
Ah, interesting. Thanks for the info. I'm hitting this on commandbox v5.0.1 and v2.8.0 of cfcollection or 5.4.2 and 2.10.2. So must be a similar thing?
b
Dunno, I can't reproduce it so ¯\_(ツ)_/¯
It's possible the new version of jGit in the latest CommandBox is what allows it to work now
d
Not positive of the Lucee versions off the top of my head, but it sounds like that matters too. I think it was 5.2.x and 5.3.6 with each combination above, respectively.
b
@danmurphy Can you give it a quick test on CommandBox 5.5.1 when you get a chance?
d
Will do tomorrow. Thanks!
b
👌
d
@bdw429s It looks like installing cfcollection 2.10.2 (which failed on CommandBox 5.4.2) gives the same error with CommandBox 5.5.1.
b
Hmm, dunno then. I can't reproduce this
I have an idea why it's happening
That folder is different between the master branch and the 2.x tags
CommandBox clones the repo and then checks out the branch/tag/commit and I think those files may be untracked in some of the tags and tracked in other tags, but I'm just guessing
It's also worth noting the 2.x versions of cfcollection are very old
d
Right - I just didn’t want to address whatever breaking changes might have happened yet.
b
I have a feeling this boils down to a bug in JGit's checkout command
d
You can’t reproduce the error if you try to 
install cfcollection@2.10.2
though? That would be really weird, right?
b
I couldn't reproduce on 
2.8.0
which is the one you were using yesterday
That would be really weird, right?
I don't think anything is weird any longer. I've seen too many things that defy reason 🙂
😂 1
Copy code
❯ install cfcollection@2.10.2 --verbose
 √ | Installing package [forgebox:cfcollection@2.10.2]
   |----------------------------------------------------------------
   | Verifying package 'cfcollection' in forgebox, please wait...
   | Installing version [2.10.2].
   | Verified entry in forgebox: 'cfcollection'
   | Deferring to [github] endpoint for forgebox entry [cfcollection]...
   | Using branch [v2.10.2]
   | Cloning Git URL [<https://github.com/elpete/cfcollection.git>]
   | remote: Enumerating objects
   | remote: Counting objects (45)
   | remote: Compressing objects (43)
   | Receiving objects (17931)
   | Resolving deltas (3814)
   | Checking out files (74)
   | Available branches are refs/heads/master,refs/remotes/origin/dependabot/npm_and_yarn/is-my-json-valid-2.20.0,refs/remotes/origin/dependabot/npm_and_yarn/macaddress-0.2.9,refs/remotes/origin/dep
   | endabot/npm_and_yarn/marked-0.3.19,refs/remotes/origin/dependabot/npm_and_yarn/sshpk-1.16.1,refs/remotes/origin/dependabot/npm_and_yarn/stringstream-0.0.6,refs/remotes/origin/development,refs/r
   | emotes/origin/master,refs/remotes/origin/transducers
   | Storing download in artifact cache...
   | Done.
   | C:\sandbox\rewritespace\/box.json updated with dependency.
   | Installing to: C:\sandbox\rewritespace\/modules/cfcollection
   | -> 11 File(s) Installed
   | -> 17 File(s) ignored
   | Eureka, 'cfcollection@2.10.2' has been installed!
d
Yeah - the error happens in certain combinations of commandbox and cfcollection, it seems.
b
I'm on CommandBox 5.5.1 and java 11.0.6
d
Wow, you really didn’t get the error though.
Ah, java version. Didn’t think about that.
b
nope
I'm on Windows. You?
d
Mac.
b
Could have something to do with that
is your FS case sensitive?
d
But can reproduce this in our Docker environment just the same.
b
Just guessing- there's so many factors at play
JGit may have different code paths it takes internally based on the OS or FS
d
No on the case sensitivity, locally at least. Probably within the Docker environment.
Well, I’ll take this as, get all the things more current (cfcollection, java, etc.). Thanks for the troubleshooting though.
b
Someone should probably get a repro case together to try and submit a ticket to JGit
Not that they may much attention to tickets 😕
Lots of hits on Google for the error message
Have you read through all of those?
Do you have any process that may be writing to those files as soon as they are cloned?
Pretty much all the hits on Google say this happens when you are pulling commits and have local changes
d
I read through a bunch that all seemed related to random repos. I didn’t realize the common thread might have been jGit.
I have blown away my entire modules folder and this still happens, but maybe the conflicting files are with commandbox or jGit somewhere?
b
well yes, JGit is the library throwing the error, lol
CommandBox is just asking JGit to clone the repo and check out the branch, that's all
JGit is the one failing
Sadly my life is now reduced to tracking down a million bugs in a million 3rd party libraries these days 😕
😳 1
e
He exaggerates. It's only 834,223 bugs in 432 libraries. 😉
😁 2
b
When I asked if a process could be modifying the files, I mean something running in the background that may immediately be writing ot them as soon as they are placed on disk. basically interfering with the clone command.
e
Have we tested with the entire box.json Dan is using?
It could be the clone command is somehow overwriting paths in the wrong folders.
d
Hmm, right. Not that I can think of. The only thing would be some kind of cfformat command maybe, but we pin down the directories we watch and I don’t have that running atm.
Good question. No, not with my specific box.json file.
b
@danmurphy Good news-- I am able to reproduce this in a docker container
Copy code
docker run -it foundeo/minibox box install cfcollection@2.10.2 --verbose
So maybe it's related to a *nix file system
d
My coworker can reproduce it as well.
b
minibox is just a CommandBox light instance so there's nothing else going on there
d
(he is on a Mac as well)
b
@danmurphy I think I figured it out
In my docker container test, I cd'd into the temp folder where the Git repo was being checked out
When I run
Copy code
git status
It shows
Copy code
modified:   tests/resources/app/handlers/Main.cfc
which means there ARE local modifications to that file
When I diff the file
Copy code
git diff tests/resources/app/handlers/Main.cfc
I see this:
Copy code
index cf160826..b3391953 100644
--- a/tests/resources/app/handlers/Main.cfc
+++ b/tests/resources/app/handlers/Main.cfc
@@ -1 +1 @@
-component extends="coldbox.system.EventHandler"{MM     // Default ActionM      function index(event,rc,prc){M          prc.welcomeMessage = "Welcome to ColdBox!";M            event.setView("main/i
ndex");M        }MM     // Do somethingM        function doSomething(event,rc,prc){M            setNextEvent("main.index");M    }MM     /************************************** IMPLICIT ACTIONS ****
*****************************************/MM    function onAuthenticationFailure( event, rc, prc ) {MM  }MM     function onAuthorizationFailure( event, rc, prc ) {MM   }MM     function onAppInit(ev
ent,rc,prc){MM  }MM     function onRequestStart(event,rc,prc){MM        }MM     function onRequestEnd(event,rc,prc){MM  }MM     function onSessionStart(event,rc,prc){MM        }MM     function onSe
ssionEnd(event,rc,prc){M                var sessionScope = event.getValue("sessionReference");M         var applicationScope = event.getValue("applicationReference");M }MM     function onException(
event,rc,prc){M         //Grab Exception From private request collection, placed by ColdBox Exception HandlingM         var exception = prc.exception;M         //Place exception handler below:MM
        }MM     function onMissingTemplate(event,rc,prc){M              //Grab missingTemplate From request collection, placed by ColdBoxM              var missingTemplate = event.getValue("missing
Template");MM   }MM}M
\ No newline at end of file
+component extends="coldbox.system.EventHandler"{M      // Default ActionM      function index(event,rc,prc){M          prc.welcomeMessage = "Welcome to ColdBox!";M            event.setView("main/i
ndex");M        }M      // Do somethingM        function doSomething(event,rc,prc){M            setNextEvent("main.index");M    }M      /************************************** IMPLICIT ACTIONS ****
*****************************************/M     function onAuthenticationFailure( event, rc, prc ) {M   }M      function onAuthorizationFailure( event, rc, prc ) {M    }M      function onAppInit(ev
ent,rc,prc){M   }M      function onRequestStart(event,rc,prc){M }M      function onRequestEnd(event,rc,prc){M   }M      function onSessionStart(event,rc,prc){M }M      function onSessionEnd(event,r
c,prc){M                var sessionScope = event.getValue("sessionReference");M         var applicationScope = event.getValue("applicationReference");M }M      function onException(event,rc,prc){M
                //Grab Exception From private request collection, placed by ColdBox Exception HandlingM         var exception = prc.exception;M         //Place exception handler below:M       }M
        function onMissingTemplate(event,rc,prc){M              //Grab missingTemplate From request collection, placed by ColdBoxM              var missingTemplate = event.getValue("missingTemplate
");M    }M}M
\ No newline at end of file
Which reminded me that the line endings were all jacked up in the repo for this file
e
BOM?
b
no
it's not encoding
it's line endings
e
The }M
b
if you view the file on github, it's also messed up
Luis used to have this issue on his mac back before Git had automatic line endings
e
I had this with some files copied from coldbox at one point.
I had the do a dos2unix command on them to fix them.
And then commit.
I can check that for this repo.
b
d
Yeah, I remember that specifically with layout files, if copied from the default ColdBox layout.
b
So what's happening here is when Git checks out the files, I'm fairly sure it's auto-fixing the messed up line endings
e
Yup. That's it.
b
And that makes the file show as modified
d
Interesting!
b
So the subsequent checkout command fails
FWIW, CommandBox also has a built in utility for fixing line endings
Copy code
line-endings ?
If you can get those fixed on the master branch, that may fix this
Since what CommandBox does is • clone repo which will be on default branch (master, usually) • checkout commitish that was asked for
So as long as we can get master to clone cleanly, switching to the tag should be fine
And FWIW, I still think this should be logged as a bug in JGit because I just did a test clone with the Git CLI and it clones with no location modifications
So JGit is doing something differently
And since it's most likely windows line endings which are in the file, that also would make sense why Windows had no issues since those line endings were fine there.
it was only on *nix that JGit tried to "fix" them
d
Well, that was some good investigative work @bdw429s.
e
This is now fixed on the latest, but the latest is 3.6.4.
2.10.2 was August 2017
3.6.3 was at least February 2020. 😉
d
Thanks for getting this fixed! Trying to go through the updates here…it is painful, ha. It has become a chain of events that is dipping into qb returnFormat now. I’ll post in the main thread again about what I’m seeing.
2 Views
Open in Slack
PreviousNext
Powered by