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

[kennethtan]

Hi,

So I have been trying to tackle this problem for an entire month now but nothing I've tried works. I need to build an R package on merges to master and then deploy said package to the renv cellar for use in other projects. I have R 4.2.2 installed and both R CMD and Rscript added to path. I've had a .cpanel.yml file that has been working up to Feb 11th that looks like the one below:

---
deployment:
  tasks:
    - export PROJROOT=/home/user/projectdir
    - Rscript -e "renv::restore()"

This was to test that the deployment works as expected as it is my first time using the feature for our codebase. Up to that point, everything has been fine and Last Deployment Information shows the correct info. Since then I have updated the codebase as well as the YAML file and this is what I currently have:

---
deployment:
  tasks:
    - export RENV_CELLAR=$(Rscript -e "cat(Sys.getenv(\"RENV_PATHS_CELLAR\"))")
    - export XXX_PKG="XXX"
    - export XXX_VERSION="0.0.0.9000"
    - export LOG_PATH=${HOME}"/R/logs/"
    - export LOG_FILE=${XXX_PKG}"_Rcheck_"$(date "+%Y.%m.%d-%H.%M.%S")
    - Rscript -e "renv::restore()"
    - R CMD build .
    - R CMD check ${XXX_PKG}"_"${XXX_VERSION}".tar.gz" --no-manual -o ${LOG_PATH}
    - /bin/mv ${LOG_PATH}${XXX_PKG}".Rcheck" ${LOG_PATH}${LOG_FILE}
    - /bin/mv ${XXX_PKG}"_"${XXX_VERSION}".tar.gz" -t ${RENV_CELLAR}

I have been pushing code almost daily but the Last Deployment Information always shows Feb 11 with that old commit. Whenever I click on Deploy HEAD commit, I get the following message:

The deployment that you triggered on Mar 8, 2023 3:56:45 PM is complete. Updating last deployment information …

Yet, the Last Deployment Information still shows the old one after a few seconds when it updates. (And yes, I have verified that nothing has been executed). When I run these commands line by line manually in the terminal without elevated access from the repository root, everything works as intended.
Is there a fix for this? Am I missing something?

edit: cpanel and whm version is 11.108.0.14, sorry I didn't realize I pasted the wrong thing

 

[cPRex]

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 <remote>.  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.

 

[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 <remote>.  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!

 

[cPRex]

I'm glad to hear things are working well now!