Skip to main content

GIT Deployment - claims new changes have been deployed but deployment info is from previous deployment

Comments

3 comments

  • cPRex Jurassic Moderator
    Hey there! In general, I find Git threads don't go well here, because very few people use it for cPanel so not many people are familiar with it. I.........am one of those people that also doesn't use it, but I reached out to the developers and they had the following suggestions: My first question would be is the user pushing to the same remote that the system is pulling from? You"d want to do a 'git remote -v' on the user side and compare the push URL to whatever is configured for the system (though I"m not sure where that would be). To verify the contents of the remote machine that they are pushing to, you can use 'git ls-remote' before and after pushing: e.g. git ls-remote --heads . That will confirm a change happens on the remote machine. However, I don"t think that"s the problem at all " this would be more of a sanity check if nothing else worked. You could also modify the script to print the current commit via 'git rev-parse HEAD' to ensure the right commit is being processed Variables are never quoted, but hardcoded strings are. For variable assignment, this is fine " the first word (i.e. argument) Bash will not do "word splitting", so any variables with a space will keep that space. However, when a command is run, word splitting will occur if a space is found. This can occasionally be desirable, though it is often preferable to quote the variable to avoid word splitting. With mv -t $VALUE, I suspect word splitting would be a bad thing. Of course, all of this is moot if none of the variables contain whitespace, which is usually the case. I don"t think the script *needs* changes, though they could be beneficial
    If none of that gets you in the right direction, it would be best to open a ticket so we can do some additional testing on the machine.
    0
  • kennethtan
    Hey there! In general, I find Git threads don't go well here, because very few people use it for cPanel so not many people are familiar with it. I.........am one of those people that also doesn't use it, but I reached out to the developers and they had the following suggestions: My first question would be is the user pushing to the same remote that the system is pulling from? You"d want to do a 'git remote -v' on the user side and compare the push URL to whatever is configured for the system (though I"m not sure where that would be). To verify the contents of the remote machine that they are pushing to, you can use 'git ls-remote' before and after pushing: e.g. git ls-remote --heads . That will confirm a change happens on the remote machine. However, I don"t think that"s the problem at all " this would be more of a sanity check if nothing else worked. You could also modify the script to print the current commit via 'git rev-parse HEAD' to ensure the right commit is being processed Variables are never quoted, but hardcoded strings are. For variable assignment, this is fine " the first word (i.e. argument) Bash will not do "word splitting", so any variables with a space will keep that space. However, when a command is run, word splitting will occur if a space is found. This can occasionally be desirable, though it is often preferable to quote the variable to avoid word splitting. With mv -t $VALUE, I suspect word splitting would be a bad thing. Of course, all of this is moot if none of the variables contain whitespace, which is usually the case. I don"t think the script *needs* changes, though they could be beneficial
    If none of that gets you in the right direction, it would be best to open a ticket so we can do some additional testing on the machine.

    Ah, thanks for the speedy reply. I am pulling and pushing to the same remote, so there's no third party service such as GitHub or Bitbucket at work here. I'll keep the whitespace thing in mind, but with my current project there are no whitespaces in any of the paths, variables, or filenames. I tried printing the commit being processed to a file right at the start of the script and verified that the correct commit was being processed. This led me to believe that the script failed somewhere in the R commands but no error was being printed to the console (would be nice if we could view the console log for latest deployment). I did try out a few more things, and the one that worked was purging the cache and manually doing `renv::restore()` again (presumably it got rid of some stale R packages) before redeploying the HEAD commit. Now deployment is working fine again, thanks for the help!
    0
  • cPRex Jurassic Moderator
    I'm glad to hear things are working well now!
    0

Please sign in to leave a comment.