search

MatMoul / archdi-pkg

Arch Linux Desktop Installer Packages
GNU General Public License v3.0
46 stars 27 forks source link

Use GitHub 'release' feature instead of pkg.tar #30

Open TheLinuxNinja opened 5 years ago

TheLinuxNinja commented 5 years ago

I'd like to see using the GitHub 'release' feature instead of creating an uncompressed tarball for the archdi to pull. This would do the work for you, and you wouldn't be maintaining a binary artifact in your source control repo.

See: https://help.github.com/en/articles/creating-releases

and: https://developer.github.com/v3/repos/releases/#create-a-release

The endpoint URL for archdi would use the release instead of pulling pkg.tar from master branch. GitHub users like myself would also benefit by following the same process for archdi -t (pulling from contributor releases instead of pkg.tar in specified branch). Maybe a new option flag would allow for this if the old method is desired to be kept around by those not wanting to use the Releases method, but GitHub will create the tar for you as a release instead of committing a tarball to source control.

MatMoul commented 5 years ago

Using release for this package need time and can have side effects, I'm not sure it's a good solution.

Firstli, the pkg.tar is only on the master branch that is not the source. The develop branche is the source without pkg.tar

Secondly, with this solution archdi download always the script on the same adress.

Thirdly, to publish a new release, I just need to launch the makerelease script, very easy and speed... Rewriting this script is complex.

Forthly, with archdi, you can test directly a github branch and this feature can be breaked.

MatMoul commented 5 years ago

After rereading my code, I've just saw that pkg.tar is made and committed in the develop branch. I'll try to remove the pkg.tar from the develop branch these next days.

TheLinuxNinja commented 5 years ago

The bigger issue with committing a binary to git is that every copy of the binary you've ever committed is part of git history and retrieved when the repo is cloned. Try running a 'git diff' between two commits where the .tar file changed. You'll see that git simply tells you the binary file differs, which means it stored an entirely new copy of the binary for each commit. Source code text files only differ on specific lines of text, so the space consumed by multiple commits is only a single copy of the text file plus the specific lines that changed.

The .tar is an 'artifact': the resulting output of the source code. It shouldn't be 'part' of the source code. Many places I've worked have had repos where .jar files and .tar.gz files were committed to git, which eventually leads to impossibly long clone times, and a ridiculous amount of disk space consumed compared to the size of the source files.

I am interested in your workflow and adapting it to using GitHub's built-in ability to delivering a compressed archive of a repo. archdi's ability to pull the latest version of archdi-pkg, or a user's own, should still work. I'll make some time to do a proof-of-concept that addresses your concerns and still satisfies the tools' requirements. It is absolutely possible. A more seasoned git pro could probably do this in just a few minutes, but that's not me.

Thanks!

MatMoul commented 5 years ago

a few minute?

The pkg.tar is very small and the clone speed isn't impacted now. I've some other priorities before working on it but issue stay open as TODO