Conversation
The Git LFS signing cert has changed, so update the default signing cert SHA-1 hash in the Makefile.
Since we now start these array literals with "[" instead of "%w(", close
them with "]" instead of ")".
SLES 12.4 is not a valid distribution according to PackageCloud, so we can't upload RPMs for it. Remove it from the list since it's not usable.
54689db to
4f8224b
Compare
| result = $client.put_package("git-lfs", pkg, distro_id) | ||
| result.succeeded || begin | ||
| raise "packagecloud put_package failed, error: #{result.response}" | ||
| if result.response != '{"filename":["has already been taken"]}' |
There was a problem hiding this comment.
Could you give some additional context on why this if-statement is necessary? I don't know much about packagecloud, so I'm still a bit confused after reading the commit message.
There was a problem hiding this comment.
Sure. During the release process, the upload aborted halfway through due to sles/12.4 not existing. Re-running the script causes us to attempt to re-upload the same files. If the file already exists and this conditional isn't present, PackageCloud returns this error and we throw an exception and abort the upload process, since PackageCloud doesn't allow us to upload over a file with the same name.
Instead, the thing we want to do is just ignore the fact that we've already uploaded those files and continue the process. Similarly, when we build the CentOS 6 packages, we always build the same Ruby and ronn packages, and without this change, they have to be manually deleted from the directory or the script will abort when the upload gets to them.
Hopefully this makes things a bit clearer.
There was a problem hiding this comment.
Ah okay! So we can still upload the package if we receive this "package already exists" error, we just weren't doing it before? Could you add a comment here to that effect?
There was a problem hiding this comment.
Well, not exactly. This error means we've already uploaded the package, and we can't upload it a second time, so we're ignoring the failure when we attempt to do so.
I'll add an appropriate comment.
Every time we build a release, we build new CentOS packages of Ruby and ronn, among others. These packages have the same names as the packages built during previous releases. However, attempting to upload a package with an identical name fails because PackageCloud doesn't allow us to overwrite packages in that way. To prevent the maintainer from having to delete these packages by hand, and to allow the maintainer to retry package uploads if they fail partway through, look for the error message we get if a package already exists and simply ignore it, continuing on as if no error occurred.
Now that Ubuntu 19.04 (disco) has been released, add it to the list of release that we can upload for.
4f8224b to
4f98099
Compare
The Git LFS signing cert has changed, so update the default signing cert SHA-1 hash in the Makefile. (The last update was in 2019 in PR git-lfs#3623.)
The Git LFS signing certificate for Windows binaries has changed, so we update the default signing certificate SHA-1 hash in the Makefile. (The last update was in 2019 in PR git-lfs#3623.)
The Git LFS signing certificate for Windows binaries has changed, so we update the default signing certificate SHA-1 hash in the Makefile. (The last update was in 2019 in PR git-lfs#3623.) The commands used to generate this hash were: openssl pkcs12 -info -in codesign.pfx -out foo.pem openssl x509 -text -in foo.pem -fingerprint | \ grep Fingerprint | sed 's/^SHA1 Fingerprint=//' | \ sed 's/://g' | tr [:upper:] [:lower:] h/t kb2204 for the info on the fingerprint
There are several release-related issues that I discovered while releasing 2.7.2. The first of these, of course, is the nwe signing certificate, which requires an update to the Makefile. In addition, I discovered several issues with the PackageCloud upload script, including some syntax errors and a release that PackageCloud refused to accept. Finally, I hit an additional issue with attempting to upload existing package that I've seen repeatedly before but have just hacked around; this time I finally fixed it.
I've also added Ubuntu disco as a release target, which fixes #3621. Note that I didn't use this change in this release; I simply applied it so as to not forget about it for 2.8.0.