Okay, so our current situation is that we are required to always include the JAR file as it is the file that is being deployed in the cloud. Problem is it keeps on growing the size of the repo which makes us keep on requesting a support to garbage collect the repo. Are there any solutions where in git does not track the history of the JAR file and it should always overwrite what is on the repo?
If you don't need to track the history of this jar file, a suggestion I can make is the following:
1. Rewrite history in the repo to remove this file from the repo's history (a git gc will be needed on the remote repo, after you do this and push)
Please note when you rewrite history, the commit hashes will change. As a result, pull requests that reference such commits whose hash has been changed, will lose the info related to those commits, and also any comments. If you would like to keep the pull request history, we suggest that you push the clean version of your repo to a newly created repo.
You can find more info on file removal from Git history here: https://support.atlassian.com/bitbucket-cloud/docs/maintain-a-git-repository/
2. Upload the jar file to the 'Downloads' section of the repository. You can do so either via the UI, or via API
If you upload a file with the same name as an existing file in the 'Downloads' section, then the existing file will be replaced.
For purposes of deployment, you can retrieve the file via API:
An example call:
curl --request GET -L --user user:password https://api.bitbucket.org/2.0/repositories/workspace-id/repo-slug/downloads/my_file.jar --output my_file.jar
Indeed, in case the jar file needs to be versioned, Git LFS can be used.
This way the jar file will be stored in a remote server, and the git repo will contain a pointer to this file.
@Aj De Guzman for your reference:
Please feel free to let us know if you have any questions.
If you store the jar file unzipped in git that will dramatically reduce disk usage.
Not intuitive I know but it works because by unzipping the jar before committing it allows git to run its powerful de-duplication logic against the files inside the jar file. If files inside don't change between versions they won't take up any new space.
Whereas storing the jar file directly means every inner file always requires disk even if they don't change between versions.
Hey Community! We’re willing to wager that quite a few of you not only use Bitbucket, but administer it too. Our team is excited to share that we’ll be releasing improvements throughout this month of...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events