filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
// Copyright 2016-2023, Pulumi Corporation.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
package diy
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
|
|
|
|
import (
|
2023-03-17 23:39:35 +00:00
|
|
|
"context"
|
2023-02-10 12:24:28 +00:00
|
|
|
"errors"
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
"fmt"
|
2023-03-17 23:39:35 +00:00
|
|
|
"io"
|
2023-05-02 00:33:49 +00:00
|
|
|
"path"
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
"path/filepath"
|
|
|
|
"strings"
|
|
|
|
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/encoding"
|
2023-06-28 16:02:04 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/slice"
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/tokens"
|
2023-02-10 12:24:28 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/util/contract"
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/util/fsutil"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/workspace"
|
2023-03-17 23:39:35 +00:00
|
|
|
"gocloud.dev/blob"
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
// These should be constants
|
|
|
|
// but we can't make a constant from filepath.Join.
|
|
|
|
var (
|
|
|
|
// StacksDir is a path under the state's root directory
|
2024-01-30 15:53:10 +00:00
|
|
|
// where the diy backend stores stack information.
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
StacksDir = filepath.Join(workspace.BookkeepingDir, workspace.StackDir)
|
|
|
|
|
|
|
|
// HistoriesDir is a path under the state's root directory
|
2024-01-30 15:53:10 +00:00
|
|
|
// where the diy backend stores histories for all stacks.
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
HistoriesDir = filepath.Join(workspace.BookkeepingDir, workspace.HistoryDir)
|
|
|
|
|
|
|
|
// BackupsDir is a path under the state's root directory
|
2024-01-30 15:53:10 +00:00
|
|
|
// where the diy backend stores backups of stacks.
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
BackupsDir = filepath.Join(workspace.BookkeepingDir, workspace.BackupDir)
|
|
|
|
)
|
|
|
|
|
|
|
|
// referenceStore stores and provides access to stack information.
|
|
|
|
//
|
|
|
|
// Each implementation of referenceStore is a different version of the stack
|
|
|
|
// storage format.
|
|
|
|
type referenceStore interface {
|
|
|
|
// StackBasePath returns the base path to for the file
|
|
|
|
// where snapshots of this stack are stored.
|
|
|
|
//
|
|
|
|
// This must be under StacksDir.
|
|
|
|
//
|
|
|
|
// This is the path to the file without the extension.
|
|
|
|
// The real file path is StackBasePath + ".json"
|
|
|
|
// or StackBasePath + ".json.gz".
|
2024-01-30 15:53:10 +00:00
|
|
|
StackBasePath(*diyBackendReference) string
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
|
|
|
|
// HistoryDir returns the path to the directory
|
|
|
|
// where history for this stack is stored.
|
|
|
|
//
|
|
|
|
// This must be under HistoriesDir.
|
2024-01-30 15:53:10 +00:00
|
|
|
HistoryDir(*diyBackendReference) string
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
|
|
|
|
// BackupDir returns the path to the directory
|
|
|
|
// where backups for this stack are stored.
|
|
|
|
//
|
|
|
|
// This must be under BackupsDir.
|
2024-01-30 15:53:10 +00:00
|
|
|
BackupDir(*diyBackendReference) string
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
|
|
|
|
// ListReferences lists all stack references in the store.
|
2024-01-30 15:53:10 +00:00
|
|
|
ListReferences(context.Context) ([]*diyBackendReference, error)
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
// ParseReference parses a diyBackendReference from a string.
|
|
|
|
ParseReference(ref string) (*diyBackendReference, error)
|
2023-02-10 12:24:28 +00:00
|
|
|
|
|
|
|
// ValidateReference verifies that the provided reference is valid
|
|
|
|
// returning an error if it is not.
|
2024-01-30 15:53:10 +00:00
|
|
|
ValidateReference(*diyBackendReference) error
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// projectReferenceStore is a referenceStore that stores stack
|
|
|
|
// information with the new project-based layout.
|
|
|
|
//
|
|
|
|
// This is version 1 of the stack storage format.
|
|
|
|
type projectReferenceStore struct {
|
|
|
|
bucket Bucket
|
|
|
|
|
|
|
|
// currentProject is a thread-safe way to get the current project.
|
|
|
|
currentProject func() *workspace.Project
|
|
|
|
}
|
|
|
|
|
|
|
|
var _ referenceStore = (*projectReferenceStore)(nil)
|
|
|
|
|
|
|
|
func newProjectReferenceStore(bucket Bucket, currentProject func() *workspace.Project) *projectReferenceStore {
|
|
|
|
return &projectReferenceStore{
|
|
|
|
bucket: bucket,
|
|
|
|
currentProject: currentProject,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
// newReference builds a new diyBackendReference with the provided arguments.
|
2023-02-10 12:24:28 +00:00
|
|
|
// This DOES NOT modify the underlying storage.
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *projectReferenceStore) newReference(project tokens.Name, name tokens.StackName) *diyBackendReference {
|
|
|
|
return &diyBackendReference{
|
2023-02-10 12:24:28 +00:00
|
|
|
name: name,
|
|
|
|
project: project,
|
|
|
|
store: p,
|
|
|
|
currentProject: p.currentProject,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *projectReferenceStore) StackBasePath(ref *diyBackendReference) string {
|
2023-02-10 12:24:28 +00:00
|
|
|
contract.Requiref(ref.project != "", "ref.project", "must not be empty")
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
// No need for NamePath for the StackName because it's already constrained to characters that are valid for filenames.
|
|
|
|
return filepath.Join(StacksDir, fsutil.NamePath(ref.project), ref.name.String())
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *projectReferenceStore) HistoryDir(stack *diyBackendReference) string {
|
2023-02-10 12:24:28 +00:00
|
|
|
contract.Requiref(stack.project != "", "ref.project", "must not be empty")
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
return filepath.Join(HistoriesDir, fsutil.NamePath(stack.project), stack.name.String())
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *projectReferenceStore) BackupDir(stack *diyBackendReference) string {
|
2023-02-10 12:24:28 +00:00
|
|
|
contract.Requiref(stack.project != "", "ref.project", "must not be empty")
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
return filepath.Join(BackupsDir, fsutil.NamePath(stack.project), stack.name.String())
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *projectReferenceStore) ParseReference(stackRef string) (*diyBackendReference, error) {
|
2023-02-10 12:24:28 +00:00
|
|
|
// We accept the following forms:
|
|
|
|
//
|
|
|
|
// 1. <stack-name>
|
|
|
|
// 2. <org-name>/<stack-name>
|
|
|
|
// 3. <org-name>/<project-name>/<stack-name>
|
|
|
|
//
|
|
|
|
// org-name must always be "organization".
|
|
|
|
// This matches the behavior of the Pulumi Service storage backend.
|
|
|
|
if stackRef == "" {
|
|
|
|
return nil, errors.New("stack name must not be empty")
|
|
|
|
}
|
|
|
|
|
|
|
|
var name, project, org string
|
|
|
|
split := strings.Split(stackRef, "/") // guaranteed to have at least one element
|
|
|
|
switch len(split) {
|
|
|
|
case 1:
|
|
|
|
name = split[0]
|
|
|
|
case 2:
|
|
|
|
org = split[0]
|
|
|
|
name = split[1]
|
|
|
|
case 3:
|
|
|
|
org = split[0]
|
|
|
|
project = split[1]
|
|
|
|
name = split[2]
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the provided stack name didn't include the org or project,
|
|
|
|
// infer them from the local environment.
|
|
|
|
if org == "" {
|
2024-01-30 15:53:10 +00:00
|
|
|
// diy organization MUST always be "organization"
|
2023-02-10 12:24:28 +00:00
|
|
|
org = "organization"
|
|
|
|
}
|
|
|
|
|
|
|
|
if org != "organization" {
|
|
|
|
return nil, errors.New("organization name must be 'organization'")
|
|
|
|
}
|
|
|
|
|
|
|
|
if project == "" {
|
|
|
|
currentProject := p.currentProject()
|
|
|
|
if currentProject == nil {
|
2023-12-12 12:19:42 +00:00
|
|
|
return nil, errors.New("if you're using the --stack flag, " +
|
2023-02-10 12:24:28 +00:00
|
|
|
"pass the fully qualified name (organization/project/stack)")
|
|
|
|
}
|
|
|
|
|
|
|
|
project = currentProject.Name.String()
|
|
|
|
}
|
|
|
|
|
2023-06-13 15:39:59 +00:00
|
|
|
if project != "" {
|
|
|
|
if err := tokens.ValidateProjectName(project); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
parsedName, err := tokens.ParseStackName(name)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
return p.newReference(tokens.Name(project), parsedName), nil
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *projectReferenceStore) ValidateReference(ref *diyBackendReference) error {
|
2023-02-10 12:24:28 +00:00
|
|
|
if ref.project == "" {
|
2023-12-12 12:19:42 +00:00
|
|
|
return errors.New("bad stack reference, project was not set")
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2023-04-03 21:36:44 +00:00
|
|
|
func (p *projectReferenceStore) ListProjects(ctx context.Context) ([]tokens.Name, error) {
|
2023-02-10 12:24:28 +00:00
|
|
|
path := StacksDir
|
|
|
|
|
2023-04-03 21:36:44 +00:00
|
|
|
files, err := listBucket(ctx, p.bucket, path)
|
2023-02-10 12:24:28 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, fmt.Errorf("error listing stacks: %w", err)
|
|
|
|
}
|
|
|
|
|
2023-06-28 16:02:04 +00:00
|
|
|
projects := slice.Prealloc[tokens.Name](len(files))
|
2023-02-10 12:24:28 +00:00
|
|
|
for _, file := range files {
|
|
|
|
if !file.IsDir {
|
|
|
|
continue // ignore files
|
|
|
|
}
|
|
|
|
|
|
|
|
projName := objectName(file)
|
|
|
|
if !tokens.IsName(projName) {
|
|
|
|
// If this isn't a valid Name
|
|
|
|
// it won't be a project directory,
|
|
|
|
// so skip it.
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
projects = append(projects, tokens.Name(projName))
|
|
|
|
}
|
|
|
|
|
|
|
|
return projects, nil
|
|
|
|
}
|
|
|
|
|
2023-04-29 15:52:04 +00:00
|
|
|
func (p *projectReferenceStore) ProjectExists(ctx context.Context, projectName string) (bool, error) {
|
2023-05-01 23:29:55 +00:00
|
|
|
contract.Requiref(projectName != "", "projectName", "must not be empty")
|
2023-04-29 15:52:04 +00:00
|
|
|
|
2023-05-02 00:33:49 +00:00
|
|
|
path := path.Join(StacksDir, projectName)
|
2023-04-29 15:52:04 +00:00
|
|
|
|
|
|
|
files, err := listBucket(ctx, p.bucket, path)
|
|
|
|
if err != nil {
|
2023-05-01 23:29:55 +00:00
|
|
|
return false, fmt.Errorf("list stacks at %q: %w", path, err)
|
2023-04-29 15:52:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// If files is empty, it means that project is not found in bucket
|
|
|
|
return len(files) > 0, nil
|
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *projectReferenceStore) ListReferences(ctx context.Context) ([]*diyBackendReference, error) {
|
2023-02-10 12:24:28 +00:00
|
|
|
// The first level of the bucket is the project name.
|
|
|
|
// The second level of the bucket is the stack name.
|
2023-03-17 23:39:35 +00:00
|
|
|
prefix := filepath.ToSlash(StacksDir) + "/"
|
|
|
|
iter := p.bucket.List(&blob.ListOptions{
|
|
|
|
Prefix: prefix,
|
|
|
|
// Don't set the Delimiter.
|
|
|
|
// This will treat the entire bucket as a flat list,
|
|
|
|
// returning only files under the prefix.
|
|
|
|
})
|
2023-02-10 12:24:28 +00:00
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
var stacks []*diyBackendReference
|
2023-03-17 23:39:35 +00:00
|
|
|
for {
|
|
|
|
file, err := iter.Next(ctx)
|
2023-02-10 12:24:28 +00:00
|
|
|
if err != nil {
|
2023-03-17 23:39:35 +00:00
|
|
|
if errors.Is(err, io.EOF) {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
return nil, fmt.Errorf("list bucket: %w", err)
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
|
2023-03-17 23:39:35 +00:00
|
|
|
if file.IsDir {
|
|
|
|
continue
|
|
|
|
}
|
2023-02-10 12:24:28 +00:00
|
|
|
|
2023-03-17 23:39:35 +00:00
|
|
|
// Key is in the form,
|
|
|
|
// $StacksDir/$projName/$stackName.json[.gz]
|
|
|
|
// We want to extract projName and stackName from it.
|
2023-02-10 12:24:28 +00:00
|
|
|
|
2023-03-17 23:39:35 +00:00
|
|
|
parts := strings.Split(strings.TrimPrefix(file.Key, prefix), "/")
|
|
|
|
if len(parts) != 2 {
|
|
|
|
continue // skip paths too shallow or too deep
|
|
|
|
}
|
|
|
|
projName := parts[0]
|
|
|
|
objName := parts[1]
|
2023-02-10 12:24:28 +00:00
|
|
|
|
2023-03-17 23:39:35 +00:00
|
|
|
if !tokens.IsName(projName) {
|
|
|
|
// If this isn't a valid Name
|
|
|
|
// it won't be a project directory,
|
|
|
|
// so skip it.
|
|
|
|
continue
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
|
2023-03-17 23:39:35 +00:00
|
|
|
// Skip files without valid extensions (e.g., *.bak files).
|
|
|
|
ext := filepath.Ext(objName)
|
|
|
|
// But accept gzip compression
|
|
|
|
if ext == encoding.GZIPExt {
|
|
|
|
objName = strings.TrimSuffix(objName, encoding.GZIPExt)
|
|
|
|
ext = filepath.Ext(objName)
|
|
|
|
}
|
|
|
|
|
|
|
|
if _, has := encoding.Marshalers[ext]; !has {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
// Read in this stack's information.
|
|
|
|
name := objName[:len(objName)-len(ext)]
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
parsedName, err := tokens.ParseStackName(name)
|
|
|
|
if err != nil {
|
|
|
|
// This looked like a stack file, but it wasn't a valid stack name so skip it.
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
stacks = append(stacks, p.newReference(tokens.Name(projName), parsedName))
|
2023-03-17 23:39:35 +00:00
|
|
|
}
|
2023-02-10 12:24:28 +00:00
|
|
|
return stacks, nil
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// legacyReferenceStore is a referenceStore that stores stack
|
|
|
|
// information with the legacy layout that did not support projects.
|
|
|
|
//
|
|
|
|
// This is the format we used before we introduced versioning.
|
|
|
|
type legacyReferenceStore struct {
|
|
|
|
bucket Bucket
|
|
|
|
}
|
|
|
|
|
|
|
|
var _ referenceStore = (*legacyReferenceStore)(nil)
|
|
|
|
|
|
|
|
// newLegacyReferenceStore builds a referenceStore in the legacy format
|
|
|
|
// (no project support) backed by the provided bucket.
|
|
|
|
func newLegacyReferenceStore(b Bucket) *legacyReferenceStore {
|
|
|
|
return &legacyReferenceStore{
|
|
|
|
bucket: b,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
// newReference builds a new diyBackendReference with the provided arguments.
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
// This DOES NOT modify the underlying storage.
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *legacyReferenceStore) newReference(name tokens.StackName) *diyBackendReference {
|
|
|
|
return &diyBackendReference{
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
name: name,
|
|
|
|
store: p,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *legacyReferenceStore) StackBasePath(ref *diyBackendReference) string {
|
2023-02-10 12:24:28 +00:00
|
|
|
contract.Requiref(ref.project == "", "ref.project", "must be empty")
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
return filepath.Join(StacksDir, ref.name.String())
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *legacyReferenceStore) HistoryDir(stack *diyBackendReference) string {
|
2023-02-10 12:24:28 +00:00
|
|
|
contract.Requiref(stack.project == "", "ref.project", "must be empty")
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
return filepath.Join(HistoriesDir, stack.name.String())
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *legacyReferenceStore) BackupDir(stack *diyBackendReference) string {
|
2023-02-10 12:24:28 +00:00
|
|
|
contract.Requiref(stack.project == "", "ref.project", "must be empty")
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
return filepath.Join(BackupsDir, stack.name.String())
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *legacyReferenceStore) ParseReference(stackRef string) (*diyBackendReference, error) {
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
parsedName, err := tokens.ParseStackName(stackRef)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
}
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
return p.newReference(parsedName), nil
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *legacyReferenceStore) ValidateReference(ref *diyBackendReference) error {
|
2023-02-10 12:24:28 +00:00
|
|
|
if ref.project != "" {
|
2023-12-12 12:19:42 +00:00
|
|
|
return errors.New("bad stack reference, project was set")
|
2023-02-10 12:24:28 +00:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2024-01-30 15:53:10 +00:00
|
|
|
func (p *legacyReferenceStore) ListReferences(ctx context.Context) ([]*diyBackendReference, error) {
|
2023-04-03 21:36:44 +00:00
|
|
|
files, err := listBucket(ctx, p.bucket, StacksDir)
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, fmt.Errorf("error listing stacks: %w", err)
|
|
|
|
}
|
2024-01-30 15:53:10 +00:00
|
|
|
stacks := slice.Prealloc[*diyBackendReference](len(files))
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
|
|
|
|
for _, file := range files {
|
|
|
|
if file.IsDir {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
objName := objectName(file)
|
|
|
|
// Skip files without valid extensions (e.g., *.bak files).
|
|
|
|
ext := filepath.Ext(objName)
|
|
|
|
// But accept gzip compression
|
|
|
|
if ext == encoding.GZIPExt {
|
|
|
|
objName = strings.TrimSuffix(objName, encoding.GZIPExt)
|
|
|
|
ext = filepath.Ext(objName)
|
|
|
|
}
|
|
|
|
|
|
|
|
if _, has := encoding.Marshalers[ext]; !has {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
// Read in this stack's information.
|
|
|
|
name := objName[:len(objName)-len(ext)]
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
parsedName, err := tokens.ParseStackName(name)
|
|
|
|
if err != nil {
|
|
|
|
// This looked like a stack file, but it wasn't a valid stack name so skip it.
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
stacks = append(stacks, p.newReference(parsedName))
|
filestate: Introduce referenceStore to control layout
Adds a referenceStore abstraction to control the layout of the storage,
and a legacyReferenceStore implementation based on the current layout
(that does not support projects).
This allows us to move code to determine file paths of stacks, their
histories, and their backups, all into a single component that we can
swap out for project support.
localBackendReferences keep track of the referenceStore that built them.
The primary reason for this is that when we add support for migrating a
stack state from legacy to project mode, `backend.store` will become
mutable.
For references created before the store for a backend was changed, we
still need to be able to access their original file paths, so we need to
hold onto the original referenceStore.
However, as a side-effect of this,
it's more convenient to acess paths from `ref.Foo()` rather than
`backend.foo(ref)` or `backend.store.Foo(ref)`.
In the future, we may also move stackPath to the store,
since right now the .json/.json.gz logic is duplicated in a couple
places.
Extracted from #12134
2023-03-14 00:49:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return stacks, nil
|
|
|
|
}
|