You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
As title says I would love to have a way to separate changed files (that were commited) from rest of the repository. It could help me save a TON of time and deployment proccess, although if you know any better way to deploy on a VPS, sure write me about it :D Currently I am using scp deploy from atlassian.
Thanks in advance for any help!
Hi Jan and welcome to the community!
You could use the rsync pipe instead:
I am copying from the rsync man page:
Rsync finds files that need to be transferred using a "quick check" algorithm (by default) that looks for files that have changed in size or in last-modified time. Any changes in the other preserved attributes (as requested by options) are made on the destination file directly when the quick check indicates that the file’s data does not need to be updated.
Getting a list of changed files may not be easy or straightforward, depending on the type of pipeline and how it was triggered. The following command will show changed files in the commit that triggered the build:
git diff --name-only HEAD HEAD~1
This will work if you have a pipeline running on a branches definition and you push one commit at a time. However, if you push e.g. five commits, the build will be triggered for the last commit only, and this command will miss the changed files in the previous four commits.
Figuring out how many commits you need to go back to adjust the git diff command would need to involve some scripting using our APIs. You would need to check the previous builds one by one: e.g. if the current build is number 50, first check if build 49 ran on the same branch and for the same definition, and if so, get the commit hash of the commit that triggered this build. If not, continue the process for the previous build.
For builds running on a pull-requests definition, the list of changed files in that pull request is easier to get with the following API endpoint: