Skip to content

Commit fc0a509

Browse files
chore: add terraform docs to UDR (#437)
1 parent 7a688a8 commit fc0a509

File tree

3,874 files changed

+417383
-29
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

3,874 files changed

+417383
-29
lines changed

app/utils/productConfig.mjs

Lines changed: 29 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -218,35 +218,35 @@ export const PRODUCT_CONFIG = {
218218
// versionedDocs: true,
219219
// websiteDir: 'website',
220220
// },
221-
// terraform: {
222-
// /**
223-
// * ✅ Initial migration attempt: SEEMS TO WORK
224-
// *
225-
// * TODO: determine how to handle non-"stable" releases. For example,
226-
// * `terraform` has `v1.10.x` releases that currently have the version
227-
// * number `v1.10.0-alpha20240814`, the `releaseStage` `alpha`. This
228-
// * will need to be accounted for in our new content API.
229-
// *
230-
// * TODO: `display` version for `v1.1.x` is "v1.1 and earlier". Ref:
231-
// * https://content.hashicorp.com/api/content/terraform/version-metadata?partial=true
232-
// * How should we handle this in our unified docs repo setup?
233-
// * Maybe another data point in favour of some kind of
234-
// * `_version-metadata.json` file at the top level of each versioned
235-
// * content directory? Eg we'd write out a file to:
236-
// * - content/${repoSlug}/${version}/_version-metadata.json
237-
// * This file would have _some_ of the metadata we already have here:
238-
// * https://content.hashicorp.com/api/content/terraform/version-metadata?partial=true
239-
// * and would be collected via our `gather-version-metadata` script.
240-
// */
241-
// assetDir: 'img',
242-
// basePaths: ['cli', 'internals', 'intro', 'language'],
243-
// contentDir: 'docs',
244-
// dataDir: 'data',
245-
// productSlug: 'terraform',
246-
// semverCoerce: semver.coerce,
247-
// versionedDocs: true,
248-
// websiteDir: 'website',
249-
// },
221+
terraform: {
222+
/**
223+
* ✅ Initial migration attempt: SEEMS TO WORK
224+
*
225+
* TODO: determine how to handle non-"stable" releases. For example,
226+
* `terraform` has `v1.10.x` releases that currently have the version
227+
* number `v1.10.0-alpha20240814`, the `releaseStage` `alpha`. This
228+
* will need to be accounted for in our new content API.
229+
*
230+
* TODO: `display` version for `v1.1.x` is "v1.1 and earlier". Ref:
231+
* https://content.hashicorp.com/api/content/terraform/version-metadata?partial=true
232+
* How should we handle this in our unified docs repo setup?
233+
* Maybe another data point in favour of some kind of
234+
* `_version-metadata.json` file at the top level of each versioned
235+
* content directory? Eg we'd write out a file to:
236+
* - content/${repoSlug}/${version}/_version-metadata.json
237+
* This file would have _some_ of the metadata we already have here:
238+
* https://content.hashicorp.com/api/content/terraform/version-metadata?partial=true
239+
* and would be collected via our `gather-version-metadata` script.
240+
*/
241+
assetDir: 'img',
242+
basePaths: ['cli', 'internals', 'intro', 'language'],
243+
contentDir: 'docs',
244+
dataDir: 'data',
245+
productSlug: 'terraform',
246+
semverCoerce: semver.coerce,
247+
versionedDocs: true,
248+
websiteDir: 'website',
249+
},
250250
'terraform-cdk': {
251251
assetDir: '',
252252
basePaths: ['cdktf'],

0 commit comments

Comments
 (0)