You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of this process, the packages are first built, using the appropriate mechanisms, and then a set of unit tests are executed to ensure the builds have completed correctly.
53
53
54
54
### 1.3. Package Signing & Upload
55
55
56
-
The final part of the jenkins job is triggered when either/both of the enable enableGpgSigning and uploadPackage options are selected.
56
+
The final part of the jenkins job is triggered when either/both of the enable enableGpgSigning and uploadPackage options are selected.
57
57
58
58
The Gpg signing uses the Adoptium Gpg key to sign the installer packages prior to their upload to the [Jfrog artifactory, hosted at packages.adoptium.net](https://packages.adoptium.net/)
59
59
@@ -63,7 +63,7 @@ As part of this process, the packages are first built, using the appropriate mec
63
63
64
64
Prior to building and releasing any packages, the source code that controls the process requires a number of updates. These updates typically happen once all of the linux platforms for a particular Java version have been released and the binaries uploaded to Github.
65
65
66
-
Prior to updating the source code, its important to have an understanding of how the source code is structured so that the correct files can be updated. The callout below, highlights the structure of the source code so for example underneath the linux top level directory, a selection of either jdk/jre, followed by the distribution, and then the vendor (temurin in the example), followed by the Java version.
66
+
Prior to updating the source code, its important to have an understanding of how the source code is structured so that the correct files can be updated. The callout below, highlights the structure of the source code so for example underneath the linux top level directory, a selection of either jdk/jre, followed by the distribution, and then the vendor (temurin in the example), followed by the Java version.
67
67
68
68
```
69
69
-- linux
@@ -93,7 +93,7 @@ The following sections will detail the source changes required when a release is
93
93
94
94
And additionally were an additional architecture being added (Alpine is currently only supported on x86_64 and Alpine from JDK version 21 onwards), then the <b>arch</b> field would also need appending.
95
95
96
-
Once all changes are made in the header section, its time to move on to the footer section.
96
+
Once all changes are made in the header section, its time to move on to the footer section.
97
97
98
98
```
99
99
pkgname=temurin-21
@@ -111,10 +111,10 @@ The following sections will detail the source changes required when a release is
111
111
112
112
<h5>2.1.2 The footer section (example below)</h5>
113
113
114
-
In this section, the key fields that must be amended are the architecture specific checksum, as shown below. These checksums are released alongside the binary files uploaded to Github, so these checksums can be obtained from there.
114
+
In this section, the key fields that must be amended are the architecture specific checksum, as shown below. These checksums are released alongside the binary files uploaded to Github, so these checksums can be obtained from there.
115
115
116
116
Again, were another architecture being added an additional element in the case statement below would be required, along with its checksum.
117
-
117
+
118
118
<b>NB:</b> Note how the case statement uses the values from the <b>arch</b> field in the header section to determine the correct checksum to use.
@@ -215,7 +215,7 @@ The process for updating the source files for both RHEL & Suse based distributio
215
215
This section requires updates to the following 2 fields:
216
216
217
217
<b>global spec version:</b></br> This field should be amended to the FULL version number of the release being processed, e.g , 21.0.3.0.0.9.
218
-
<b>global spec release:</b></br> This field should be reset to 0 for the first release of a package, and then incremented should there be patches or additional rebuilds of this package version. The first version should be 1. This will ultimately be appended to the final package name, e.g temurin-21-jdk-21.0.3.0.0.9-1.
218
+
<b>global spec release:</b></br> This field should be reset to 0 for the first release of a package, and then incremented should there be patches or additional rebuilds of this package version. The first version should be 1. This will ultimately be appended to the final package name, e.g temurin-21-jdk-21.0.3.0.0.9-1.
219
219
220
220
In the event that this is a new java major version release, the <b>global priority</b> should also be updated appropriately.
This file requires that the <b>.contains("Version: 1.0.4-1")</b> line be updated to reflect the new version number added to the <i>changelog</i> above.
546
+
This file requires that the <b>.contains("Version: 1.0.5-1")</b> line be updated to reflect the new version number added to the <i>changelog</i> above.
544
547
```
545
548
result = runShell(container, "apt-cache show adoptium-ca-certificates");
Copy file name to clipboardExpand all lines: linux/ca-certificates/debian/src/packageTest/java/org/adoptium/cacertificates/ChangesVerificationTest.java
0 commit comments