Add safety check when publishing unstable APIs #630
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #630 +/- ##
==========================================
- Coverage 53.55% 53.40% -0.16%
==========================================
Files 258 257 -1
Lines 20466 20352 -114
==========================================
- Hits 10960 10868 -92
+ Misses 9506 9484 -22 ☔ View full report in Codecov by Sentry. |
| @@ -33,6 +33,10 @@ pub struct Publish { | |||
| #[clap(long, short)] | |||
| force: bool, | |||
|
|
|||
| /// Allow publishing packages with unstable api versions | |||
There was a problem hiding this comment.
This help string is likely going to be misunderstood to be something related to package API compatibility / compat values or whatever.
I suggest at least expanding the description to "package spec version" or similar and it would help to briefly touch on what the dangers are for enabling this or at least mention that enabling it might be dangerous.
There was a problem hiding this comment.
Done, let me know what you think. Github is being slow to update so in case it doesn't, I changed it to:
/// Allow publishing package specs written in unstable api versions
///
/// The api version of a spec is the value of the `api` field within it.
#[clap(long)]
allow_unstable_api: bool,
| } | ||
|
|
||
| impl RecipeApiVersion { | ||
| pub fn is_stable(&self) -> bool { |
There was a problem hiding this comment.
Presumably some future build of spk will have a newer recipe API version flipped to "stable" but that new build may not be in common use yet or fully deployed.
What versions are allowed to be published to a repo could be a property of the repo rather than the spk client. For example, if I configured our production "origin" repo to not accept "v1" packages until we have fully deployed v1-aware builds of spk everywhere and have retired non-v1-aware builds, then I would know that nobody would be able to publish packages to origin (accidentally or otherwise) that might break tools in production.
I'm reminded how simple things like spk ls stopped working when we were in a transition period between python and rust, because ls would crap out the first chance it got if it saw a package it didn't like.
There was a problem hiding this comment.
Our goal, I believe, is still to ignore packages in a repo that are invalid. That being said, I think this is definitely an idea to explore, but if it's the same to you I'd like to start with this as it's a lot less involved. We can then circle back when the v1 is actually being discussed and when we start to re-open conversations on migration
There was a problem hiding this comment.
Since we last talked about this, an spk conf file got added. I think it would go a long way to address my concern if we could have this "is_stable" method return something defined the conf file, if present, otherwise it can default to v0.
There was a problem hiding this comment.
The goal of is_stable was specifically for things like v1beta where the version itself is not considered stable by definition. Perhaps we need a separate concept for versions that are considered acceptable to publish that can be configured?
rydrman
force-pushed
the
296-unstable-api-check
branch
from
3eeb66d to
16f012f
Compare
rydrman
force-pushed
the
296-unstable-api-check
branch
from
16f012f to
9c0c829
Compare
|
From the meeting today:
|
Signed-off-by: Ryan Bottriell <[email protected]>
rydrman
force-pushed
the
296-unstable-api-check
branch
from
9c0c829 to
a6a69cb
Compare
|
Pinging this again for a review |
This feels a little unnecessary without the additional definition of the new API type, but I'm leaving that part in #598 so that this can be merged separately.