Provide default app version for the plugin version#10
Conversation
Oleg-Melnik
left a comment
Oleg-Melnik
left a comment
There was a problem hiding this comment.
Clean, well-scoped simplification: dropping rolling latest removes a large amount of branching (the HEAD/redirect resolver, the latest cache branch, version.txt/resolvedVersionFile, selectedVersionName, deleteSafely, and all the latest-check-failure fallback), and it retires the earlier footgun where sha256 paired with rolling latest would hard-fail on a new upstream release. Verified two things worth calling out as safe: (1) removing version.txt does not weaken tag binding, because the tag is already encoded in releaseAssetIdentity(baseUrl, releaseTag, asset) (the source-identity check), and different tags land in different versions/<hash> directories; (2) pinning the default to v1.2.4 incidentally insulates the default install path from the upcoming upstream Linux-asset .zip rename, since v1.2.4 still ships the bare embed-code-linux (only users who bump version to a future zip-only release would hit that). Two non-blocking suggestions inline. I reviewed the diff only and did not run the build or tests.
| } | ||
|
|
||
| val embedCodeAppVersion = rootProject.extra["embedCodeAppVersion"] as String | ||
| val generateEmbedCodeVersion = tasks.register<Sync>("generateEmbedCodeVersion") { |
There was a problem hiding this comment.
Nice pattern for baking in the default version. One hardening opportunity now that the default version is fixed at plugin-build time: the default install path (default version, default downloadBaseUrl, no sha256) still resolves the asset digest from api.github.com on first install via resolveTrustedAssetSha256. That's an unauthenticated GitHub API call, and it's the most common path — on shared CI runner IPs it can hit the 60/hour limit and fail a clean build for reasons unrelated to the user's config.
Since this task already knows the default version, consider also generating the default per-platform SHA-256 digests into EmbedCodeVersionDefaults.kt (fetched at plugin-build time and baked in), and short-circuiting the metadata request when version == default and the user configured no sha256. That would make the default path verify without any GitHub API call at all. More build machinery, so reasonable to defer — but it closes the last unauthenticated-API dependency for the common case.
There was a problem hiding this comment.
To resolve issue with github rate limit it is possible to provide the GitHub authentication, which will bypass unauth limit.
| package io.spine.embedcode.gradle | ||
|
|
||
| /** The Embed Code release bundled by default with this plugin version. */ | ||
| internal const val DEFAULT_EMBED_CODE_VERSION: String = "v@embedCodeAppVersion@" |
There was a problem hiding this comment.
The v prefix is hardcoded here while version.gradle.kts stores the bare embedCodeAppVersion = "1.2.4", so the release-tag scheme is split across two files. If upstream ever publishes a non-v tag (or changes the scheme), this template silently produces a wrong tag. Minor, but storing the full tag (v1.2.4) in the extra property — or deriving it in one place — keeps the tag format in a single source of truth.
There was a problem hiding this comment.
The upstream is our application, and we are not supposed to change this behavior.
Oleg-Melnik
left a comment
Oleg-Melnik
left a comment
There was a problem hiding this comment.
@Vladyslav-Kuksiuk LGTM with minor comments.
2 participants
This PR removes support for the latest version and requires users to either use the default Embed Code application version or explicitly specify a version tag.