Give the background. . . Only the technical manager of the company's development team has server and database permissions, and it is only for the development environment. . Because of work arrangement and permission restrictions, when test students go online, they need to help some colleagues in the development team review the code and submit the code to trunk. At the beginning, manually diff files and copy and upload them. After a long time, a firm trust has been established among colleagues, and non-important files do not need to be reviewed. I was too troublesome to write a shell script (trunk.sh), put the files to be uploaded and the comment in two files (fileList and comment), manually execute the script, and copy the script to the trunk directory after verifying the file, and then svn commit to trunk. Recently, the development students have frequently changed the online, and the test students sent me files desperately, which seriously affected my development work, and finally gave me the motivation to write a small system. On the development server, I created a form for submitting files to be uploaded after logging in, and assigned account passwords to test students. After logging in, test students filled in the file list and change instructions, filtered important files, and saved them to memcached. I wrote a script (getTask.php) locally using crontab to request the task.php of the development server every minute (the role of task.php is to output and delete the new task of memcached when it finds it), getTask.php requests to The new task writes the file and comment in the previous fileList and comment, and writes the timestamp in the current_task_time file. Another script (autosvn.sh) compares current_task_time and last_task_time every minute, executes `cp current_task_time last_task_time` if different and executes trunk.sh, if current_task_time and last_task_time are the same, do nothing.
After the background is explained, let's talk about the pits encountered when crontab regularly submits svn. The first is that trunk.sh can be executed manually (of course, it has been used countless times within a year). But using crontab to execute regularly, I received an error message. I have encountered two errors from Baidu search.
1. A relative path is used in the script. The script does use some relative paths for convenience.
2. The crontab environment variable is different from the environment variable for manual execution. Add env to the script and find that the output is indeed different. (Solution: add source ~/.bash_profile in front of the timing script).
Solved these two problems.
It was found that two svn errors were reported again
svn: E170013: Unable to connect to a repository at URL 'https://svn.*****.com:10443/******'
svn: E215004: No more credentials or we tried too many times.
Authentication failed
Searched a lot online and couldn't find a solution. Finally, I asked my classmate Dashen and said that I had entered the account password and cached it when I manually executed it. crontab did not help me enter the account password, and asked me if crontab is the current login user, I said yes. The classmates have no idea, let me search for svn login-free. Not found. Try to bring --username and --password, the execution is successful. I thought I was finally done. . .
But when I want to submit the code myself, the manual svn up even has to enter the password. I can't figure out the caching mechanism of the svn account password. Guess that the account password should be entered when crontab is executed, but the password is not saved, so the password I cached before is flushed out.
The idea is in a dilemma. The timed svn script can succeed without password, but I have to enter the password when I submit it myself. After entering the password and remembering it myself, the timing script can't remember it again. . .
Later, I found --no-auth-cache and then I deliberately svn up --no-auth-cache without entering the password, and pressed Enter three times. I got an error.
svn: E215004: No more credentials or we tried too many times.
Authentication failed
Suddenly, it turns out that even if crontab is the same user as manually executing svn, it will not have the cached password of this user before, and because it cannot enter the account password and continue to run, it will report the error of svn: E215004 for multiple input errors. There are two doubts here:
First, why does crontab not use my cached passwords.
second. How to let crontab support me to manually enter the password and cache it (there is a useful expect script on the Internet that can enter the account password for the user).
Finally, I tried the svn command in trunk.sh with --username myaccount --password mypassword and --no-auth-cache, the execution was successful, and then manually executing svn did not let me enter the account password again.
But I still feel uncomfortable with the svn account and password in the script. When I have time, I will find out how to configure svn so that crontab executes svn without logging in.