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

fix(service-version): Allow 'locked' services to be activated. #1245

Merged
merged 2 commits into from
Aug 13, 2024

Conversation

kpfleming
Copy link
Contributor

@kpfleming kpfleming commented Jul 9, 2024

This PR changes the ServiceDetailsOpts structure (used by the ServiceDetails function) to permit commands to specify individual service states as part of the filtering mechanism. Nearly all commands allow both 'active' and 'locked' services, and previously 'service-version activate' blocked both, but it should allow 'locked' while still blocking 'active'.

Additionally, the error message emitted when the specified service is not allowed by the filter now indicates whether it was the 'active' or 'locked' status which caused the error.

Closes #1191.

@kpfleming kpfleming marked this pull request as ready for review July 10, 2024 15:34
@kpfleming kpfleming marked this pull request as draft July 10, 2024 15:37
@kpfleming kpfleming marked this pull request as ready for review July 10, 2024 15:45
@kpfleming kpfleming requested a review from Integralist July 10, 2024 15:45
@kpfleming kpfleming marked this pull request as draft July 10, 2024 20:47
@kpfleming kpfleming removed the request for review from Integralist July 10, 2024 20:47
@kpfleming kpfleming force-pushed the issue-1191 branch 3 times, most recently from 6048ddb to 89cdc81 Compare August 7, 2024 19:27
@kpfleming kpfleming marked this pull request as ready for review August 7, 2024 19:43
@kpfleming kpfleming requested review from jsocol and Integralist August 7, 2024 19:43
@Integralist
Copy link
Collaborator

It looks like a third-party dependency has been manually copied into the repo?

From what I can tell the original code came from https://github.com/leighmcculloch/go-optional

We should be adding this as a dependency to the CLI go.mod

e.g. go get https://github.com/leighmcculloch/go-optional@latest followed by go mod tidy once the dependency is referenced in the codebase itself)

@kpfleming
Copy link
Contributor Author

The new package has now been added to go.mod as a normal dependency.

@kpfleming
Copy link
Contributor Author

Unfortunately go mod tidy is not happy about the replace specification.

@Integralist
Copy link
Collaborator

I'll take a look on Monday and see what we can do

Copy link
Collaborator

@Integralist Integralist left a comment

Choose a reason for hiding this comment

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

Other than the issue with go mod tidy which I'll look at Monday, this LGTM

@Integralist
Copy link
Collaborator

Yeah I think we'll just have to use the import path used in that optional project...

diff --git a/go.mod b/go.mod
index b1c9b1bc..aaed6c53 100644
--- a/go.mod
+++ b/go.mod
@@ -79,8 +79,4 @@ require (
 	gopkg.in/yaml.v3 v3.0.1 // indirect
 )
 
-require (
-    github.com/leighmcculloch/go-optional v0.2.0
-)
-
-replace github.com/leighmcculloch/go-optional => 4d63.com/optional v0.2.0
+require 4d63.com/optional v0.2.0

diff --git a/pkg/argparser/cmd.go b/pkg/argparser/cmd.go
index 50e9ce62..3be4104b 100644
--- a/pkg/argparser/cmd.go
+++ b/pkg/argparser/cmd.go
@@ -13,7 +13,7 @@ import (
 	"github.com/fastly/cli/pkg/global"
 	"github.com/fastly/cli/pkg/manifest"
 	"github.com/fastly/cli/pkg/text"
-	optional "github.com/leighmcculloch/go-optional"
+	"4d63.com/optional"
 )

@kpfleming
Copy link
Contributor Author

I know there are strong opinions about this topic, and I'm fairly new to the Golang community, but how would you feel about using 'go mod vendor' here? I'm mostly concerned about build reproducibility. Most of our dependencies are heavily-used packages and aren't likely to be a problem, but this one (optional) is not and could disappear.

@kpfleming
Copy link
Contributor Author

After discussion with various knowledgeable Go users we've decided to stick with the 'vanity path' used for the optional module.

This PR changes the ServiceDetailsOpts structure (used by the
ServiceDetails function) to permit commands to specify individual
serviceversion states as part of the filtering mechanism. Nearly all
commands allow both 'active' and 'locked' serviceversions, and
previously 'service-version activate' blocked both, but it should
allow 'locked' while still blocking 'active'.

Additionally, the error message emitted when the specified
serviceversion is not allowed by the filter now indicates whether it
was the 'active' or 'locked' status which caused the error.

Finally, many more tests were added to ensure that the proper error
messages are emitted for 'active' and 'locked' serviceversions in many
of the commands which specify filters.
@kpfleming kpfleming merged commit ecba357 into fastly:main Aug 13, 2024
6 checks passed
@kpfleming kpfleming deleted the issue-1191 branch August 13, 2024 12:14
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.

Can't activate locked service version: "service version is not editable"
3 participants