-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Docker scripts #511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker scripts #511
Conversation
docker/README.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a fenced code syntax error. You can use just a `.
I need to create disposable clean copies of the repo and pass them into the container instead of linking them for this. Keep the current dockers for easy to debug
Started readme
I had 5 ways forward, I picked #6 1) don't sign. That's generally only acceptable for private packages 2) Make whomever edited the changelog last create signed .deb and .dsc. This seems like a pain for whomever is developing the packages 3) Change the changelog to a uid in the signing.key. I did not like taking credit away from whomever SHOULD be in the changelog 4) Have the distributing person add the changelog email address as an additional uid in their pgp key... this sounds like bad practice to me. 5) Build the .deb package, break it apart, manually sign, and re- archive. While possible, seemed prone to failure in corner cases down the road... 6) Use -p option of pgp to point to a script removing the the --local-user option that was forcing the .deb to be signed by the last developer of the changelog, not the person generating the distributions. This seemed best... Does not handle the public key yet in Debian
Added ./docker/test_dockers.bsh in order to test if the repo files are working. Got REPO_HOSTNAME env variable working for centos and debian Standardized the archive filename for git-lfs.spec
Fixed git clean to only be in build_rpms for centos path Added tests for all distros Added some options like GPG cache, and auto remove Fixed rpm expect script to work always Enabled gpg check for centos repos Fixed golang build bug for CentOS 5
Can now test all distros and sign all distro
Having the repos directory in the docker directory causes it to be sent to the docker daemon every time, which is a complete waste. Best solution was to move the repos dir out of dockers
Update docs
No more unbound error
Image build off of 0.5.3 instead of master (less docker rebuilding) Fixed small bug with clean script Fixed does not delete empty key (less docker rebuilding)
|
I think this is ready to merge once the formatting in the md file is fixed (I left a comment last week about it). I was able to build all the docker VMs and Git LFS packages on my mac. There's probably more to be done here, but since this code isn't compiled and run as part of git lfs, I think it's fine. EDIT: Also, I'm being a little selfish since I have to deal with the docker/repos subdirectories now when I work in other branches. Those are included in the |
|
There, I think I got them all. Thanks! |
docker/README.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you put backticks around the _? The markdown rendering is italicizing the rest of the text below.
Fixing bug
In commit c2d25ee of PR git-lfs#511 we added support for building RPM packages for 32-bit platforms by updating the docker/centos_script.bsh script which was present at that time to call rpmbuild with a --target=i686 argument. Since commit 56ffe42 of PR git-lfs#555 both that script and the rpm/build_rpms.bsh script contained the same logic to parse the OS name and version in order to set a short suffix for the RPM filenames. However, the docker/centos_script.bsh script was subsequently moved into the git-lfs/build-dockers repository, where it has not been updated to match the rpm/build_rpms.bsh script, such as when parsing of the OS major version was added in commit e939409 of PR git-lfs#5054, which allows us to properly parse the version number on CentOS/Rocky Linux 8 and above, or when parsing of the Rocky Linux OS name was added in commit 723be34 of PR git-lfs#5144. The result is that at present we build 32-bit RPMs for CentOS 8 and Rocky Linux 9 (el8 and el9, respectively) without the platform short name suffix in their filenames, e.g., git-lfs-3.3.0-1.i686.rpm and git-lfs-3.3.0-1.i686.rpm, and then upload them to Packagecloud with those names. To resolve this problem and avoid later regressions between the two sets of parsing logic, we move the rpmbuild command for 32-bit packages into our rpm/build_rpms.bsh script, which ensures they will be built with the same context as our 64-bit packages. To do this we introduce an rpmbuild command with the --target=i686 argument into rpm/build_rpms.bsh, which allows us to also remove the rpmbuild command from the centos_script.bsh script in the git-lfs/build-dockers repository in PR git-lfs/build-dockers#54.
In commit git-lfs/git-lfs@c2d25ee of PR git-lfs/git-lfs#511 we added support for building RPM packages for 32-bit platforms by updating the docker/centos_script.bsh script which was present at that time to call rpmbuild with a --target=i686 argument. Since commit git-lfs/git-lfs@56ffe42 of PR git-lfs/git-lfs#555 both that script and the rpm/build_rpms.bsh script in the primary Git LFS project's repository contained the same logic to parse the OS name and version in order to set a short suffix for the RPM filenames. However, the docker/centos_script.bsh script was subsequently moved into this repository, where it has not been updated to match the rpm/build_rpms.bsh script in the primary project repository, such as when parsing of the OS major version was added in commit git-lfs/git-lfs@e939409 of PR git-lfs/git-lfs#5054, which allows us to properly parse the version number on CentOS/Rocky Linux 8 and above, or when parsing of the Rocky Linux OS name was added in commit git-lfs/git-lfs@723be34 of PR git-lfs/git-lfs#5144. The result is that at present we build 32-bit RPMs for CentOS 8 and Rocky Linux 9 (el8 and el9, respectively) without the platform short name suffix in their filenames, e.g., git-lfs-3.3.0-1.i686.rpm and git-lfs-3.3.0-1.i686.rpm, and then upload them to Packagecloud with those names. To resolve this problem and avoid later regressions between the two sets of parsing logic, we add an rpmbuild command with the --target=i686 argument for 32-bit packages to the rpm/build_rpms.bsh script in the primary Git LFS project repository in commit git-lfs/git-lfs@7830f04 of PR git-lfs/git-lfs#5241, which ensures they will be built with the same context as our 64-bit packages. We can therefore also remove the rpmbuild command with the --target=i686 argument from the centos_script.bsh script in this repository, along with the setup code which attempted to parse the OS version and name from either /etc/os-release or /etc/redhat-release, as these values are only used to set the RPM_DIST variable passed to rpmbuild, and the initialization code for that variable can be removed as well.
When the scripts to build Docker images of Git LFS were first introduced in PRs git-lfs#511 and git-lfs#555, an optional capabililty was included to sign the RPM or Debian packages after building them in the containers. This option was triggered by the presence of a git-lfs_*.key file alongside the Dockerfile for a given OS and version. However, we have not published Docker containers to the Docker Hub or any other registry for at least five years, and we do not use or maintain this signing capability, so we can remove the associated script code. If we ever decide to begin publishing containers again, we can restore this functionality from our Git history. The docker/test_dockers.bsh script is also out of date and unused, so we remove it as well.
A set up docker scripts useful for building, packaging, signing, and testing on multiple Linuxes from a single Linux
@ssgelm I could use your help on adding some Debian repos deb. That's the only part missing here.