Skip to content

SK-3222 fix internal release #439

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.

Sign up for GitHub

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

Merged
skyflow-bharti merged 1 commit into from
Oct 16, 2026
Merged

SK-3222 fix internal release #439

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/internal-release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ jobs:
uses: ./.github/workflows/shared-build-and-deploy.yml
with:
ref: ${{ github.ref_name }}
server-id: central
server-id: skyflow-jfrog
profile: jfrog
tag: 'internal'
module: ${{ needs.resolve-module.outputs.module }}
Expand Down
31 changes: 12 additions & 19 deletions flowvault/pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -76,25 +76,18 @@
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<!-- Comparison-only jar merging com.skyflow:common, mirroring skyvault. This
exists so japicmp compares the whole surface a consumer actually gets, since
classes a customer imports (Credentials, SkyflowException, BearerToken) live
in common and would otherwise read as missing - japicmp only sees what is
physically inside the jars it is given.
Written with outputFile, NOT shadedArtifactAttached: attaching it made it a
secondary artifact, and every attached artifact is deployed, so this
build-internal jar was being published to Maven Central as a permanent
-with-common classifier. outputFile writes the jar and neither replaces the
main artifact nor attaches it. The path is unchanged, so the japicmp
newVersion path below still resolves. -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.6.0</version>
<executions>
<execution>
<!-- Comparison-only jar merging com.skyflow:common, mirroring skyvault. This
exists so japicmp compares the whole surface a consumer actually gets, since
classes a customer imports (Credentials, SkyflowException, BearerToken) live
in common and would otherwise read as missing - japicmp only sees what is
physically inside the jars it is given.
Written with outputFile, NOT shadedArtifactAttached: attaching it made it a
secondary artifact, and every attached artifact is deployed, so this
build-internal jar was being published to Maven Central as a permanent
-with-common classifier. outputFile writes the jar and neither replaces the
main artifact nor attaches it. The path is unchanged, so the japicmp
newVersion path below still resolves. -->
<id>shade-for-japicmp</id>
<phase>package</phase>
<goals>
Expand Down Expand Up @@ -180,7 +173,7 @@
<id>jfrog</id>
<distributionManagement>
<repository>
<id>central</id>
<id>skyflow-jfrog</id>
<name>prekarilabs.jfrog.io-releases</name>
<url>https://prekarilabs.jfrog.io/artifactory/skyflow-java</url>
</repository>
Expand Down
33 changes: 13 additions & 20 deletions skyvault/pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,26 +57,19 @@
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<!-- Produces an additional, comparison-only jar that merges in
com.skyflow:common, same pattern flowvault already uses. It exists only so
japicmp can compare an apples-to-apples "everything a v2 consumer gets" surface
against the old 2.1.0 baseline, which was a single self-contained jar
(predating the common/v2 split). Without this, classes that moved into
common (Credentials, ErrorCode, BearerToken, Token, etc.) would show up as
false-positive "removed" classes, since japicmp only compares what's
physically inside the two jars it's given.
Written with outputFile rather than shadedArtifactAttached: attaching it made
it a secondary artifact, and attached artifacts are deployed, so a jar
documented here as comparison-only was being published. outputFile keeps it
on disk without attaching. Path unchanged, so japicmp still resolves it. -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.6.0</version>
<executions>
<execution>
<!-- Produces an additional, comparison-only jar that merges in
com.skyflow:common, same pattern flowvault already uses. It exists only so
japicmp can compare an apples-to-apples "everything a v2 consumer gets" surface
against the old 2.1.0 baseline, which was a single self-contained jar
(predating the common/v2 split). Without this, classes that moved into
common (Credentials, ErrorCode, BearerToken, Token, etc.) would show up as
false-positive "removed" classes, since japicmp only compares what's
physically inside the two jars it's given.
Written with outputFile rather than shadedArtifactAttached: attaching it made
it a secondary artifact, and attached artifacts are deployed, so a jar
documented here as comparison-only was being published. outputFile keeps it
on disk without attaching. Path unchanged, so japicmp still resolves it. -->
<id>shade-for-japicmp</id>
<phase>package</phase>
<goals>
Expand Down Expand Up @@ -170,7 +163,7 @@
<id>jfrog</id>
<distributionManagement>
<repository>
<id>central</id>
<id>skyflow-jfrog</id>
<name>prekarilabs.jfrog.io-releases</name>
<url>https://prekarilabs.jfrog.io/artifactory/skyflow-java</url>
</repository>
Expand Down
Loading