You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/architecture.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Kernel Terraform Provider Architecture
2
2
3
-
This document records the durable-only architecture, the implemented v0 baseline, and the target scope for the first public v1 of the Kernel Terraform provider.
3
+
This document records the durable-only architecture, the initial public v0.0.1 surface, and the target scope for a future v1 of the Kernel Terraform provider.
4
4
5
5
## First Principles
6
6
@@ -42,7 +42,7 @@ Import:
42
42
43
43
## v1 Target Scope
44
44
45
-
The first public v1 should make durable Kernel configuration production-ready without turning Terraform into a runtime control plane. Core items are release-blocking unless the release notes explicitly defer them with an upstream API or SDK blocker.
45
+
A future v1 should broaden production-ready durable Kernel configuration without turning Terraform into a runtime control plane.
46
46
47
47
Resources require stable identity, refresh, delete, import, and, where applicable, project-scoping and sensitive-state semantics. Data sources require stable identity, deterministic exact lookup, and, where applicable, masked sensitive metadata, pagination, and project scoping. Tooling experiments require deterministic regeneration and must preserve the handwritten lifecycle boundary.
48
48
@@ -268,4 +268,4 @@ Release checklist:
268
268
- Runtime operations are absent from Terraform resources.
269
269
- Import behavior is documented.
270
270
- API and SDK blockers are either resolved or explicitly deferred.
271
-
- Release process, signing, licensing, and versioning are complete before the first public v1 publication.
271
+
- Release process, signing, licensing, and versioning are complete before the first public v0.0.1 publication.
Copy file name to clipboardExpand all lines: docs/release.md
+61-10Lines changed: 61 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ Use this checklist before publishing a Kernel Terraform provider version.
4
4
5
5
## Release Preconditions
6
6
7
-
- The repository has no published provider tags. Present v1 as the first public release, not as an upgrade or migration from v0.
7
+
- The repository has no published provider tags. Present v0.0.1 as the first public release, not as an upgrade or migration from an earlier provider version.
8
8
- Review the [first public release guide](first-release.md) and include its supported-surface and import guidance in the release notes.
9
9
- Work from a clean `main` checkout after the PR stack is merged.
10
10
- Run `bash scripts/check-docs.sh`.
@@ -28,12 +28,41 @@ Use this checklist before publishing a Kernel Terraform provider version.
28
28
- Verify unscoped API calls send no `X-Kernel-Project-Id` header; it is sent only when a resource-level `project_id` or the provider default resolves a project.
29
29
- Confirm `terraform-registry-manifest.json` contains protocol `["6.0"]` for Terraform Plugin Framework.
30
30
- Confirm `LICENSE` contains the approved Apache License 2.0 text.
31
+
- Confirm immutable GitHub Releases are enabled for the repository. The
32
+
publication job intentionally has no repository-administration permission to
33
+
inspect or change this setting.
31
34
- Confirm GitHub private vulnerability reporting or a public security contact is configured and reflected in `SECURITY.md`.
32
-
- Confirm there is no branch named like the release tag, for example `v1.0.0`.
35
+
- Create a protected GitHub environment named `release`, require approval from
36
+
the designated release owners, prevent self-review, and disable administrator
37
+
bypass. Add exactly two deployment policies: the `main` branch for manual
38
+
preflight and tags matching `v*` for publication. Store
39
+
`GPG_PRIVATE_KEY` and `PASSPHRASE` as environment secrets, not repository
40
+
secrets. Set the environment variable `GPG_FINGERPRINT` to the fingerprint
41
+
registered with the Terraform Registry. Set `RELEASE_REVIEWERS` to the exact
42
+
comma-separated reviewer identities in `Type:name` form, such as
43
+
`User:octocat,Team:release-owners`. GitHub's environment API does not report
44
+
whether administrator bypass is disabled, so verify that setting when
45
+
approving a release.
46
+
- Add a repository ruleset that restricts creation, update, and deletion of
47
+
`v*` tags to the designated release owners. Set the `release` environment
48
+
variable `RELEASE_RULESET_ID` to that active ruleset's numeric ID. The workflow
49
+
verifies the live environment reviewer identities, deployment policies, and
50
+
ruleset controls before
51
+
touching signing configuration. Before setting the ID, inspect the ruleset's
52
+
bypass list and require explicit release-owner teams or GitHub Apps; do not
53
+
allow repository roles or organization administrators to bypass it. GitHub
54
+
omits bypass actors from ruleset API responses unless the caller has ruleset
55
+
write access, so the least-privilege workflow cannot verify their identities
56
+
at runtime.
57
+
- GitHub repository writers can create Releases through the API; GitHub does not
58
+
provide a separate release-publisher role. Treat every account with repository
59
+
write access as release-authorized, keep that group minimal, and use the
60
+
protected environment to restrict access to the signing key.
61
+
- Confirm there is no branch named like the release tag, for example `v0.0.1`.
33
62
34
63
## Registry Release Assets
35
64
36
-
Terraform Registry provider releases are GitHub Releases with semver tags prefixed by `v`, such as `v1.0.0`.
65
+
Terraform Registry provider releases are GitHub Releases with semver tags prefixed by `v`, such as `v0.0.1`.
37
66
38
67
Each release must include:
39
68
@@ -61,13 +90,34 @@ Do not replace or mutate assets for a published version. If an asset, checksum,
61
90
platforms, checksums, manifest inclusion, and checksum signing.
62
91
- Normal CI validates the GoReleaser configuration and registry manifest without
63
92
building the complete platform matrix.
64
-
-`.github/workflows/release.yml` prepares unsigned, unpublished assets for
65
-
stable `vMAJOR.MINOR.PATCH` tags after confirming the repository is public
66
-
and the tag commit is reachable from `main`. It pins GoReleaser to the pushed
67
-
tag, verifies the release contract, and retains the assets for seven days.
68
-
- Real releases sign the checksum file once with the GPG key selected by
69
-
`GPG_FINGERPRINT`. The detached signature is named by appending `.sig` to the
70
-
checksum filename. Publication remains a separate release step.
93
+
-`.github/workflows/release.yml` runs for `v*` tags. Its preparation job has
94
+
read-only repository access and accepts only stable `vMAJOR.MINOR.PATCH`
95
+
versions. It requires the Apache 2.0 license, public repository visibility,
96
+
and a commit reachable from `main`, then builds and verifies the unsigned
97
+
assets. The workflow artifact is retained for seven days. Only the protected
98
+
publication job receives `contents: write`.
99
+
- Before creating a tag, run the workflow manually with the intended version.
100
+
Manual runs create an unpushed tag only inside the ephemeral runner, build
101
+
the same unsigned assets, and enter the protected `release` environment to
102
+
verify its reviewer, tag policy, ruleset, checksum, and GPG signing
103
+
configuration. They never create a remote tag or GitHub Release.
104
+
- For the manual preflight, inspect the prepared artifact before approving the
105
+
protected `release` job. After approval, the job verifies the release
106
+
protections, checksums, and GPG signing configuration without publishing.
107
+
- For a tag-triggered release, confirm the acceptance matrix passed and the tag
108
+
ruleset's bypass list still contains only designated release owners before
109
+
approving the protected `release` job. After approval, the job revalidates the
110
+
tag and checksums, requires the imported key to match `GPG_FINGERPRINT`, signs
111
+
the checksum file, and publishes the GitHub Release.
112
+
- Failed-job reruns reuse the prepared artifact from the same workflow run. A
113
+
full rerun replaces that run's artifact and requires a fresh environment
114
+
approval. If publication fails or is interrupted, it may leave a draft. Any
115
+
existing draft stops retries until a release owner inspects and removes it
116
+
manually. An existing published release always stops the workflow.
117
+
- For `v0.0.1`, GitHub includes the tagged
118
+
[first public release guide](first-release.md) with the generated release
119
+
notes. Later versions use generated release notes without first-release
0 commit comments