Fix more Linux package issues #3932
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since this script is executable and it isn't a native binary, it needs a shebang. Add one.
CentOS 8 has recently gained a new version of tar. This version of tar is sensitive about the order of its operands and only applies the --exclude arguments to file arguments following them. As a result, this version of tar ignores the exclude arguments altogether, which results in us trying to recursively copy the contents of the tmptar directory into itself until the operation fails because the file name is too long. Predictably, this results in a failed build for CentOS 8. To avoid that, place the --exclude options before the file arguments so that they apply correctly and the build succeeds.
When we build a pre-release tag, we don't want to upload the packages to packagecloud, since they would have a number greater than the main release, but we still want to build them. Check if the tag is a pre-release tag and don't upload it to packagecloud.
Currently we only build Linux packages during the release process. This means that there is a significant period of time during which unrelated changes could silently break the Linux package build. Since having this happen is a hassle resulting in the maintainer doing the release having to build the packages by hand, we should check this process during CI to ensure that any errors are caught early. Add a CI job which builds Linux packages as normal but doesn't upload them anywhere, so that we can ensure that the packages continue to build.
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Sep 6, 2024
Since commit 9b0adeb of PR git-lfs#3125, when we converted our test suite to use the "prove" command, we have run up to nine test jobs in parallel in our primary test builds. However, as of commit 7fd5aa6 in PR git-lfs#3144, we only use a maximum of four parallel test jobs when building our Linux RPM packages. This has the effect of slowing down our CI suite, because, ever since commit 212c051 in PR git-lfs#3932, we build a range of Linux packages in our GitHub Actions CI workflow. (Note that for historical reasons, we only run the full "make test" Makefile target in our "t" test directory when building RPM packages; in our Debian packages, we just run the Go language tests. While this discrepency is worth addressing, for the moment we simply aim to improve the runtime of our RPM package builds.)
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Sep 8, 2024
Since commit 9b0adeb of PR git-lfs#3125, when we converted our test suite to use the "prove" command, we have run up to nine test jobs in parallel in our primary test builds. However, as of commit 7fd5aa6 in PR git-lfs#3144, we only use a maximum of four parallel test jobs when building our Linux RPM packages. This has the effect of slowing down our CI suite, because, ever since commit 212c051 in PR git-lfs#3932, we build a range of Linux packages in our GitHub Actions CI workflow. (Note that for historical reasons, we only run the full "make test" Makefile target in our "t" test directory when building RPM packages; in our Debian packages, we just run the Go language tests. While this discrepency is worth addressing, for the moment we simply aim to improve the runtime of our RPM package builds.)
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Sep 15, 2024
Since commit 9b0adeb of PR git-lfs#3125, when we converted our test suite to use the "prove" command, we have run up to nine test jobs in parallel in our primary test builds. However, as of commit 7fd5aa6 in PR git-lfs#3144, we only use a maximum of four parallel test jobs when building our Linux RPM packages. This has the effect of slowing down our CI suite, because, ever since commit 212c051 in PR git-lfs#3932, we build a range of Linux packages in our GitHub Actions CI workflow. (Note that for historical reasons, we only run the full "make test" Makefile target in our "t" test directory when building RPM packages; in our Debian packages, we just run the Go language tests. While this discrepency is worth addressing, for the moment we simply aim to improve the runtime of our RPM package builds.)
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Oct 5, 2024
Since commit 9b0adeb of PR git-lfs#3125, when we converted our test suite to use the "prove" command, we have run up to nine test jobs in parallel in our primary test builds. However, as of commit 7fd5aa6 in PR git-lfs#3144, we only use a maximum of four parallel test jobs when building our Linux RPM packages. This has the effect of slightly slowing down our CI suite, because, ever since commit 212c051 in PR git-lfs#3932, we build a range of Linux packages in our GitHub Actions CI workflow. (Note that for historical reasons, we only run the full "make test" Makefile target in our "t" test directory when building RPM packages; in our Debian packages, we just run the Go language tests. While this discrepancy is worth addressing, for the moment we simply aim to improve the runtime of our RPM package builds.)
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Jan 25, 2025
In the "build-docker" and "build-docker-cross" jobs in our CI GitHub Actions workflow we currently install Ruby using the ruby/setup-ruby action, which has been true since we introduced the first of these jobs in commit 212c051 of PR git-lfs#3932. However, unlike the corresponding jobs in our release workflow, where we need the Ruby interpreter in order to run our script/packagecloud.rb utility at the end of the job, we do not actually require Ruby for the CI versions of these jobs, so we can simply remove the ruby/setup-ruby step from them now.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently we only build Linux packages during the release process. This means that there is a significant period of time during which unrelated changes could silently break the Linux package build. This happened the other day with CentOS 8 and a tar update.
Since having this happen is a hassle resulting in the maintainer doing the release having to build the packages by hand, we should check this process during CI to ensure that any errors are caught early. In addition, we should allow the building of prerelease tags so that any problems with the release can be caught before the main release is built.
We additionally fix the tar issue in this series, plus the lack of a shebang on the packagecloud script.
Note that the Windows build already takes longer than the newly added Linux package build should, so this should not impede the normal flow of development. git-lfs/build-dockers#30 should also speed this up somewhat.