Skip to content
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.

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

feat(cli): on update process add flag to opt-out from publishing #415

Merged
merged 7 commits into from
Oct 3, 2024

Conversation

BibiSebi
Copy link
Contributor

@BibiSebi BibiSebi commented Oct 2, 2024

What?

This PR adds a new flag to the deploy command for publishing a new version of field plugin during the update process.

Context

As we have found out trough researching the APIs the POST request automatically publishes a field-plugin, therefore it is not possible to opt-out during the initial creations. However when using PUT method, updating the plugin, it is possible to send publish property, which will either only save the new plugin or save and publish it as a new version.

Deploy Command with --no-publish flag

Here are all the new test cases that are introduced by the change and are applied when a field plugin is updated. `

yarn deploy --no-publish

yarn deploy --skipPrompts

yarn deploy --skipPrompts --no-publish

Why?

#380

How to test?

yarn deploy
--> NEW: User is prompted with the following question Do you want to publish a new version of the field plugin?
--> Depending on the user input the field plugin will be deployed

yarn deploy --skipPrompts
--> Plugin will be updated and published inside Storyblok.

yarn deploy --no-publish & yarn deploy --skipPrompts --no-publish
--> Plugin will be updated inside Storyblok but not published.

Copy link

vercel bot commented Oct 2, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
plugin-sandbox ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 3, 2024 0:27am

@@ -60,6 +60,14 @@ export const createCLI = () => {
'--name <value>',
'name of plugin (Lowercase alphanumeric and dash)',
)
.option(
Copy link
Contributor Author

@BibiSebi BibiSebi Oct 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried out this approach as described in commander.js --> https://www.npmjs.com/package/commander#other-option-types-negatable-boolean-and-booleanvalue

However I might rewrite it depending on your feedback.
The better solution to this I see is to have --publish=true|false however then --publish without value might not work. And I will need to parse and validate boolean values, but thats fine, just a heads-up :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The approach looks good to me, Bibi. 🤔

I wonder though, what if we have just the --no-publish option, and in case it's not passed (meaning it will be true), we always prompt the user to confirm the publishing unless the --skipPrompts is also present?

The combinations would be something like:

yarn deploy (which in case of an update, always asks if the user wants or not to publish)
yarn deploy --skipPrompts (publish without asking anything)
yarn deploy --no-publish (does not publish and does not show the prompt)
yarn deploy --no-publish --skipPrompts (does not publish and not show any prompt)

I didn't think deeply about it, so I may be missing some pieces 🤣 🤣

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might also work. Let's see what @eunjae-lee and @Dawntraoz think as well :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be a slight breaking change. Let's imagine someone was using deploy command with all the options except for --skipPrompts, but since all the options were given, they didn't encounter any prompt, and they used it for their CI. Now we're changing the default behavior to prompt about publishing. Then their CI will break.

So I think we can keep publishing by default, and just provide --no-publish, then it would also be clear that publishing is done by default. What do you think? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok so you would also suggest removing --publish? Works for me :) I will adjust it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@demetriusfeijoo @eunjae-lee here are the updates
a5a690e

@BibiSebi BibiSebi self-assigned this Oct 2, 2024
@BibiSebi BibiSebi requested review from eunjae-lee and demetriusfeijoo and removed request for eunjae-lee October 2, 2024 13:08
@BibiSebi BibiSebi changed the title feat(CLI): on update process add flag to opt-out from publishing feat(cli): on update process add flag to opt-out from publishing Oct 2, 2024
@BibiSebi BibiSebi assigned Dawntraoz and unassigned Dawntraoz Oct 2, 2024
@BibiSebi BibiSebi requested a review from Dawntraoz October 2, 2024 13:10
@BibiSebi BibiSebi marked this pull request as ready for review October 2, 2024 13:10
@BibiSebi BibiSebi linked an issue Oct 2, 2024 that may be closed by this pull request
@@ -378,6 +381,7 @@ export const createFieldPlugin = async (
//we need to force an update call right after the creation.
//If no options is found, it's not going to be sent to the API since undefined
//properties are not encoded.
//NOTE: The `publish` property is set to true here because it is a part of the creation process and should provide a consistent flow.
await client.updateFieldType({
id: fieldPlugin.id,
publish: true,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not 100% happy about this as it is a piece of code that might easily get overlooked, but I think keeping it to publish:true makes sense here, as it kind of mimics the creation process. So I would suggest keeping it to not confuse our users.

Comment on lines 431 to 432
//NOTE: Publish true is the default value
return publish || true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Maybe here it could be simplified like that, Bibi? wdyt?

Suggested change
//NOTE: Publish true is the default value
return publish || true
//NOTE: Publish true is the default value
return true

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @demetriusfeijoo, if skipPrompts is true, it can still be the case that the --no-publish flag was defined. If so it should be taken into account. || true is only for this case yarn deploy --skipPrompts where no publish flag is defined.

WDYT?

packages/cli/src/commands/deploy/helper.ts Show resolved Hide resolved
@@ -60,6 +60,14 @@ export const createCLI = () => {
'--name <value>',
'name of plugin (Lowercase alphanumeric and dash)',
)
.option(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The approach looks good to me, Bibi. 🤔

I wonder though, what if we have just the --no-publish option, and in case it's not passed (meaning it will be true), we always prompt the user to confirm the publishing unless the --skipPrompts is also present?

The combinations would be something like:

yarn deploy (which in case of an update, always asks if the user wants or not to publish)
yarn deploy --skipPrompts (publish without asking anything)
yarn deploy --no-publish (does not publish and does not show the prompt)
yarn deploy --no-publish --skipPrompts (does not publish and not show any prompt)

I didn't think deeply about it, so I may be missing some pieces 🤣 🤣

packages/cli/src/main.ts Outdated Show resolved Hide resolved
Co-authored-by: Demetrius Feijóo <[email protected]>
@@ -15,6 +15,7 @@ import { Scope } from '../../storyblok/storyblok-client'
export type DeployArgs = {
skipPrompts: boolean
dir: string
publish: boolean
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BibiSebi is this value coming from the flag --no-publish? Maybe I missed it, but where the flag is --no-publish is giving the value to this boolean? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah its rather weird and unintuitive but when defining -noo-publish option with commander.js

it will automatically translate it into publish:false and if you do not provide the option then it will be per default publish:true

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, next level of a smart tool 🤯 Love it!

Copy link
Contributor

@Dawntraoz Dawntraoz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 🎉

Super small nit: It can be nice to add a test with the --no-publish flag in place

@BibiSebi
Copy link
Contributor Author

BibiSebi commented Oct 3, 2024

LGTM! 🎉

Super small nit: It can be nice to add a test with the --no-publish flag in place

You are right @Dawntraoz I just added a test :)

Copy link
Contributor

@demetriusfeijoo demetriusfeijoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job @BibiSebi! 👏 👏

@BibiSebi BibiSebi merged commit a90d0b5 into main Oct 3, 2024
11 checks passed
@BibiSebi BibiSebi deleted the SHAPE-7067-add-publish-flag branch October 3, 2024 13:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Extend CLI with --publish flag option configurable
4 participants