2

I have a build process for producing RPMs. The team uses rpm release numbers to help track version information. They look like <program_name>-<version>-<rel_num>.<os_type>.<arch>.rpm; where the following are true:

  • version is the semantic version pattern MAJOR.MINOR.PATCH
  • rel_num is simply an every increasing integer stored in revision control to help make it unique
  • os_type is el7 for Enterprise Linux 7
  • arch as expected x86_64 or what have you

The project I'm working on has its source stored in git. This release number process for the RPMs is inherited from subversion (where most projects our team supports reside).

In order to maintain uniqueness, I've made a branch named rpm for the project which has a unique directory containing a file named rpm_build_num. The idea is that this file is only to reside on the rpm branch. During the make process, a BASH script is called to checkout the rpm branch, making a new branch based upon origin/rpm if it doesn't exist: increment the build number and then push it back to the remote. Once this is completed, the script restores the branch before exiting. In brief BASH

storedBranch=$(git branch | awk -e '/^\* / {print $2}')
git branch | grep -q rpm
if [[ ${PIPESTATUS[1]} != 0 ]]; then
    git checkout -b rpm origin/rpm
else
    git checkout rpm
fi

# fetch and merge origin/rpm if needed

cd path/to/dir
echo (( $(cat rpm_build_num) + 1 )) > rpm_build_num
git add rpm_buid_num
git commit -m "incrementing the build number"
git push origin rpm
cd -

git checkout ${storedBranch}

The problem is that, for reasons I don't yet understand, sometimes the make process, started from the shell prompt, gets lost with respect to which branch it's actually using. I'm being very careful in every stage of this process to start various things, like this script, from directories that exist in all branches. Yet, I still see this at times:

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

The above error prints out 4 or 5 times while make is processing a couple of lines of comments. I've had no luck fixing this with my few attempts. My internet searches have yielded many results with stuff like, "Working with branches," or, "Switching branches," but nothing that's exactly related to this. Since I cannot update a file on a different branch, commit and push it without actually changing to that branch (I did find the answer to that question), what options might I have?

Andrew Falanga
  • 2,274
  • 4
  • 26
  • 51
  • Is it possible that `git checkout -b rpm origin/rpm` or `git checkout rpm` fails? – ElpieKay Jun 24 '16 at 00:47
  • try putting `sync;sync;sync` after checkout or put some sleep to get file system sync? – YOU Jun 24 '16 at 01:18
  • @ElpieKay a good question. The actual script does check `$?` after executing the checkout. The script ultimately bails at this point if that fails and reasons are printed to stdout. – Andrew Falanga Jun 24 '16 at 14:18

2 Answers2

0

A possible workaround is to avoid the checkout entirely, meaning avoiding having to switch branches... because they would be already checked out.

Since git 2.5, you can use multiple working tree.
Make one for each branch (using git worktree add for the second working tree)
And your script only has to cd to the right folder in order to modify file and push to remote. Then cd back to the first working tree/branch.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Wow, this would truly be the answer I'm looking for (from just a quick review of the link). Unfortunately, the Linux systems on which our product is deployed are running CentOS 7 (RHEL 7). The available version of git for this Linux is 1.8.3.1: a far cry from 2.5. CentOS is stable, but that stability comes at the price of usually being **woefully old** (my opinion). Nevertheless, thanks for this. Perhaps I can persuade the right people that we need to update our systems to this version of git. – Andrew Falanga Jun 24 '16 at 14:24
  • @AndrewFalanga You can upgrade anytime you want: git compiles without any problem. – VonC Jun 24 '16 at 17:59
0

In short getcwd: cannot access parent directories: No such file or directory means that you're trying to do some things in a directory which doesn't exist anymore. It can happen in a few ways, but since you mention changing branches, something like this happens:

Your repo has layout:

repo_path/
  +- a <- you're here
  \- b

You checkout another branch and your layout changes to:

repo_path/
  +- b
  \- c

'a' exists only in memory now, but you're still in it

You run make - getcwd fails.

I can't guess which point this happens in your scripts, but in general I can recommend to make sure you cd to repository root before running git commands. If you keep it as the base for all operations, it will be harder to get confused about the state/location.

viraptor
  • 33,322
  • 10
  • 107
  • 191
  • Marked as the answer because it's the most relevant to the version of git that I'm using on EL7. In reality, I've made a solution which will use this answer and @YOU 's suggestion of a sleep with a sync in the script. Preliminary tests of this look promising. – Andrew Falanga Jun 24 '16 at 14:49