gruntwork-io · eak12913 · Jan 24, 2023 · Jan 23, 2023 · Jan 23, 2023 · Jan 23, 2023
diff --git a/docs/discussions/knowledge-base/137.mdx b/docs/discussions/knowledge-base/137.mdx
diff --git a/docs/discussions/knowledge-base/633.mdx b/docs/discussions/knowledge-base/633.mdx
@@ -0,0 +1,27 @@
+---
+hide_table_of_contents: true
+hide_title: true
+custom_edit_url: null
+---
+
+import CenterLayout from "/src/components/CenterLayout"
+import GitHub from "/src/components/GitHub"
+
+<head>
+  <link rel="canonical" href="https://github.com/gruntwork-io/knowledge-base/discussions/633" />
+</head>
+
+<CenterLayout>
+<span className="searchCategory">Knowledge Base</span>
+<h1>In the RefArch Gruntwork pipelines.yml, why are plan and deploy bundled in the same job?</h1>
+<GitHub discussion={{"id":"D_kwDOF8slf84ASJFS","number":633,"author":{"login":"umm0n"},"title":"In the RefArch Gruntwork pipelines.yml, why are plan and deploy bundled in the same job?","body":"[r:terraform-aws-ci-pipeline-example](https://github.com/gruntwork-io/terraform-aws-ci-pipeline-example)\r\n\r\nThe Gruntworks pipe for the ref arch has plan and deploy steps bundled in the same job. This causes plan to be run when merging against master, even if it was ran moments ago when pushing the changes against the branch. For large plans, this creates a big overhead in terms of time. For example:\r\n\r\n1. Create PR, push changes. Pipeline runs plan, it takes 30min.\r\n2. Merge PR. Pipeline runs plan, it takes 30min. Then pipe runs deploy, takes another 30mins.\r\n\r\nWhy are we running plan again when merging? We already know the plan, it ran as a result of creating the PR in the first place. Wouldn't it make more sense to have these steps split into separate jobs? For longer plans, the time savings could be huge when merging.\r\n\r\n---\r\n\r\n<ins datetime=\"2023-01-13T18:46:46Z\">\r\n  <p><a href=\"https://support.gruntwork.io/hc/requests/109794\">Tracked in ticket #109794</a></p>\r\n</ins>\r\n","bodyHTML":"<p dir=\"auto\"><a href=\"https://github.com/gruntwork-io/terraform-aws-ci-pipeline-example\">r:terraform-aws-ci-pipeline-example</a></p>\n<p dir=\"auto\">The Gruntworks pipe for the ref arch has plan and deploy steps bundled in the same job. This causes plan to be run when merging against master, even if it was ran moments ago when pushing the changes against the branch. For large plans, this creates a big overhead in terms of time. For example:</p>\n<ol dir=\"auto\">\n<li>Create PR, push changes. Pipeline runs plan, it takes 30min.</li>\n<li>Merge PR. Pipeline runs plan, it takes 30min. Then pipe runs deploy, takes another 30mins.</li>\n</ol>\n<p dir=\"auto\">Why are we running plan again when merging? We already know the plan, it ran as a result of creating the PR in the first place. Wouldn't it make more sense to have these steps split into separate jobs? For longer plans, the time savings could be huge when merging.</p>\n<hr>\n<ins datetime=\"2023-01-13T18:46:46Z\">\n  <p dir=\"auto\"><a href=\"https://support.gruntwork.io/hc/requests/109794\" rel=\"nofollow\">Tracked in ticket #109794</a></p>\n</ins>","answer":{"body":"One of our engineers responded internally with the following:\r\n\r\n> Terraform will run plan under the hood whenever you run apply - unless you give it the path to a saved plan output. It needs to do this in order to have the latest plan before applying. To fully answer this question, we need confirm that this is the same behavior that occurs with the ECS Deploy Runner's (Gruntwork Pipelines') internal usage for deploying new Reference Architectures.\r\n\r\nI'll also add that you're encouraged to re-configure the pipelines configurations however you'd like. If you want to pass a plan output between steps to avoid running plan again, you could use something like [CircleCI Artifacts](https://circleci.com/docs/artifacts/) or [GitHub Actions Artifacts](https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts).\r\n\r\nOnce we've completed the internal research, we'll update this thread again.\r\n","bodyHTML":"<p dir=\"auto\">One of our engineers responded internally with the following:</p>\n<blockquote>\n<p dir=\"auto\">Terraform will run plan under the hood whenever you run apply - unless you give it the path to a saved plan output. It needs to do this in order to have the latest plan before applying. To fully answer this question, we need confirm that this is the same behavior that occurs with the ECS Deploy Runner's (Gruntwork Pipelines') internal usage for deploying new Reference Architectures.</p>\n</blockquote>\n<p dir=\"auto\">I'll also add that you're encouraged to re-configure the pipelines configurations however you'd like. If you want to pass a plan output between steps to avoid running plan again, you could use something like <a href=\"https://circleci.com/docs/artifacts/\" rel=\"nofollow\">CircleCI Artifacts</a> or <a href=\"https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts\">GitHub Actions Artifacts</a>.</p>\n<p dir=\"auto\">Once we've completed the internal research, we'll update this thread again.</p>"}}} />
+
+</CenterLayout>
+
+
+<!-- ##DOCS-SOURCER-START
+{
+  "sourcePlugin": "github-discussions",
+  "hash": "9ac3a4eccd04e7183889ba6bb7edadee"
+}
+##DOCS-SOURCER-END -->
diff --git a/docs/discussions/knowledge-base/636.mdx b/docs/discussions/knowledge-base/636.mdx
@@ -0,0 +1,27 @@
+---
+hide_table_of_contents: true
+hide_title: true
+custom_edit_url: null
+---
+
+import CenterLayout from "/src/components/CenterLayout"
+import GitHub from "/src/components/GitHub"
+
+<head>
+  <link rel="canonical" href="https://github.com/gruntwork-io/knowledge-base/discussions/636" />
+</head>
+
+<CenterLayout>
+<span className="searchCategory">Knowledge Base</span>
+<h1>Additional Subnet apart from Public, Private App and Persistent</h1>
+<GitHub discussion={{"id":"D_kwDOF8slf84ASLPe","number":636,"author":{"login":"bangupoc"},"title":"Additional Subnet apart from Public, Private App and Persistent","body":"\nHi Team,\r\n\r\nCurrently we can see 1) Public, 2) Private App and 3) Persistent Subnets [Supported Subnets](https://docs.gruntwork.io/guides/build-it-yourself/vpc/core-concepts/subnets)are been supported and the logic is present in the VPC modules. If we need to add additional subnet apart from these what is the best approach. \r\nAs per documentation extend the catalog its mentioned but not sure if this is right approach for this requirement. [extend-service](https://docs.gruntwork.io/reference/services/intro/create-your-own-service-catalog#extend-gruntwork-services)\n\n---\n\n<ins datetime=\"2023-01-17T11:54:23Z\">\n  <p><a href=\"https://support.gruntwork.io/hc/requests/109798\">Tracked in ticket #109798</a></p>\n</ins>\n","bodyHTML":"<p dir=\"auto\">Hi Team,</p>\n<p dir=\"auto\">Currently we can see 1) Public, 2) Private App and 3) Persistent Subnets <a href=\"https://docs.gruntwork.io/guides/build-it-yourself/vpc/core-concepts/subnets\" rel=\"nofollow\">Supported Subnets</a>are been supported and the logic is present in the VPC modules. If we need to add additional subnet apart from these what is the best approach.<br>\nAs per documentation extend the catalog its mentioned but not sure if this is right approach for this requirement. <a href=\"https://docs.gruntwork.io/reference/services/intro/create-your-own-service-catalog#extend-gruntwork-services\" rel=\"nofollow\">extend-service</a></p>\n<hr>\n<ins datetime=\"2023-01-17T11:54:23Z\">\n  <p dir=\"auto\"><a href=\"https://support.gruntwork.io/hc/requests/109798\" rel=\"nofollow\">Tracked in ticket #109798</a></p>\n</ins>","answer":{"body":"Yes, extending by wrapping would be the correct approach. You might have to customize the cidr blocks, but you can use the outputs from the vpc-app module to create the necessary extra subnets & routes. ","bodyHTML":"<p dir=\"auto\">Yes, extending by wrapping would be the correct approach. You might have to customize the cidr blocks, but you can use the outputs from the vpc-app module to create the necessary extra subnets &amp; routes.</p>"}}} />
+
+</CenterLayout>
+
+
+<!-- ##DOCS-SOURCER-START
+{
+  "sourcePlugin": "github-discussions",
+  "hash": "6f93ce1943fe7edb9eb921114261750a"
+}
+##DOCS-SOURCER-END -->
diff --git a/docs/discussions/knowledge-base/642.mdx b/docs/discussions/knowledge-base/642.mdx
@@ -0,0 +1,27 @@
+---
+hide_table_of_contents: true
+hide_title: true
+custom_edit_url: null
+---
+
+import CenterLayout from "/src/components/CenterLayout"
+import GitHub from "/src/components/GitHub"
+
+<head>
+  <link rel="canonical" href="https://github.com/gruntwork-io/knowledge-base/discussions/642" />
+</head>
+
+<CenterLayout>
+<span className="searchCategory">Knowledge Base</span>
+<h1>How do I ensure a GitHub Personal Acccess token (PAT) is valid?</h1>
+<GitHub discussion={{"id":"D_kwDOF8slf84ASQYz","number":642,"author":{"login":"zackproser"},"title":"How do I ensure a GitHub Personal Acccess token (PAT) is valid?","body":"\nA customer asked: \r\n> How can I ensure a given GitHub Personal Access Token (PAT) is still valid?\n\n---\n\n<ins datetime=\"2023-01-23T20:34:21Z\">\n  <p><a href=\"https://support.gruntwork.io/hc/requests/109822\">Tracked in ticket #109822</a></p>\n</ins>\n","bodyHTML":"<p dir=\"auto\">A customer asked:</p>\n<blockquote>\n<p dir=\"auto\">How can I ensure a given GitHub Personal Access Token (PAT) is still valid?</p>\n</blockquote>\n<hr>\n<ins datetime=\"2023-01-23T20:34:21Z\">\n  <p dir=\"auto\"><a href=\"https://support.gruntwork.io/hc/requests/109822\" rel=\"nofollow\">Tracked in ticket #109822</a></p>\n</ins>","answer":{"body":"# Step 1. Install GitHub's official `gh` command line tool\r\n[Official installation instructions](https://github.com/cli/cli#installation)\r\n\r\n# Step 2. Export the token to test as `GH_TOKEN`\r\n`export GH_TOKEN=<the-github-pat>`\r\n\r\n# Step 3. Run `gh auth status`\r\n\r\n`gh auth status`\r\n\r\n![out](https://user-images.githubusercontent.com/1769996/214150704-2bbb6fc8-28b8-4447-9d72-5ecff797208d.gif)\r\n\r\n\r\n","bodyHTML":"<h1 dir=\"auto\">Step 1. Install GitHub's official <code class=\"notranslate\">gh</code> command line tool</h1>\n<p dir=\"auto\"><a href=\"https://github.com/cli/cli#installation\">Official installation instructions</a></p>\n<h1 dir=\"auto\">Step 2. Export the token to test as <code class=\"notranslate\">GH_TOKEN</code></h1>\n<p dir=\"auto\"><code class=\"notranslate\">export GH_TOKEN=&lt;the-github-pat&gt;</code></p>\n<h1 dir=\"auto\">Step 3. Run <code class=\"notranslate\">gh auth status</code></h1>\n<p dir=\"auto\"><code class=\"notranslate\">gh auth status</code></p>\n<p dir=\"auto\"><a target=\"_blank\" rel=\"noopener noreferrer nofollow\" href=\"https://user-images.githubusercontent.com/1769996/214150704-2bbb6fc8-28b8-4447-9d72-5ecff797208d.gif\"><img src=\"https://user-images.githubusercontent.com/1769996/214150704-2bbb6fc8-28b8-4447-9d72-5ecff797208d.gif\" alt=\"out\" data-animated-image=\"\" style=\"max-width: 100%;\"></a></p>"}}} />
+
+</CenterLayout>
+
+
+<!-- ##DOCS-SOURCER-START
+{
+  "sourcePlugin": "github-discussions",
+  "hash": "ce3967705f4e54129cb835917698951e"
+}
+##DOCS-SOURCER-END -->
diff --git a/docs/discussions/knowledge-base/643.mdx b/docs/discussions/knowledge-base/643.mdx
@@ -0,0 +1,27 @@
+---
+hide_table_of_contents: true
+hide_title: true
+custom_edit_url: null
+---
+
+import CenterLayout from "/src/components/CenterLayout"
+import GitHub from "/src/components/GitHub"
+
+<head>
+  <link rel="canonical" href="https://github.com/gruntwork-io/knowledge-base/discussions/643" />
+</head>
+
+<CenterLayout>
+<span className="searchCategory">Knowledge Base</span>
+<h1>How do I determine which scopes are attached to a GitHub token?</h1>
+<GitHub discussion={{"id":"D_kwDOF8slf84ASQaO","number":643,"author":{"login":"zackproser"},"title":"How do I determine which scopes are attached to a GitHub token?","body":"\nA customer asked: \r\n> How can I determine which scopes are attached to a given GitHub Personal Access Token (PAT)? \r\n\r\n\n\n---\n\n<ins datetime=\"2023-01-23T21:17:25Z\">\n  <p><a href=\"https://support.gruntwork.io/hc/requests/109823\">Tracked in ticket #109823</a></p>\n</ins>\n","bodyHTML":"<p dir=\"auto\">A customer asked:</p>\n<blockquote>\n<p dir=\"auto\">How can I determine which scopes are attached to a given GitHub Personal Access Token (PAT)?</p>\n</blockquote>\n<hr>\n<ins datetime=\"2023-01-23T21:17:25Z\">\n  <p dir=\"auto\"><a href=\"https://support.gruntwork.io/hc/requests/109823\" rel=\"nofollow\">Tracked in ticket #109823</a></p>\n</ins>","answer":{"body":"You can use the following command to make a call to GitHub's API, supplying the GitHub personal access token (PAT) in question and requesting that curl only return the response headers: \r\n\r\n`curl -H \"Authorization: Bearer $GH_TOKEN\" https://api.github.com/user -Is | grep x-oauth-scopes`\r\n\r\nGitHub's API returns the scopes attached to a given token in the `x-oauth-scopes` response header, like so: \r\n\r\n`x-oauth-scopes: repo:invite, repo:status`\r\n\r\nThe above response indicates the token set in `$GH_TOKEN` only had the `repo:invite and repo:status` permissions attached to it. If, instead ALL repo permissions had been attached, you'd find this header response from GitHub: \r\n\r\n`x-oauth-scopes: repo` - which indicates that ALL permissions under the `repo` section have been applied to the token. \r\n\r\n![out](https://user-images.githubusercontent.com/1769996/214152904-e0212b72-d90f-4a92-80ef-ead7bc6a3380.gif)\r\n","bodyHTML":"<p dir=\"auto\">You can use the following command to make a call to GitHub's API, supplying the GitHub personal access token (PAT) in question and requesting that curl only return the response headers:</p>\n<p dir=\"auto\"><code class=\"notranslate\">curl -H \"Authorization: Bearer $GH_TOKEN\" https://api.github.com/user -Is | grep x-oauth-scopes</code></p>\n<p dir=\"auto\">GitHub's API returns the scopes attached to a given token in the <code class=\"notranslate\">x-oauth-scopes</code> response header, like so:</p>\n<p dir=\"auto\"><code class=\"notranslate\">x-oauth-scopes: repo:invite, repo:status</code></p>\n<p dir=\"auto\">The above response indicates the token set in <code class=\"notranslate\">$GH_TOKEN</code> only had the <code class=\"notranslate\">repo:invite and repo:status</code> permissions attached to it. If, instead ALL repo permissions had been attached, you'd find this header response from GitHub:</p>\n<p dir=\"auto\"><code class=\"notranslate\">x-oauth-scopes: repo</code> - which indicates that ALL permissions under the <code class=\"notranslate\">repo</code> section have been applied to the token.</p>\n<p dir=\"auto\"><a target=\"_blank\" rel=\"noopener noreferrer nofollow\" href=\"https://user-images.githubusercontent.com/1769996/214152904-e0212b72-d90f-4a92-80ef-ead7bc6a3380.gif\"><img src=\"https://user-images.githubusercontent.com/1769996/214152904-e0212b72-d90f-4a92-80ef-ead7bc6a3380.gif\" alt=\"out\" data-animated-image=\"\" style=\"max-width: 100%;\"></a></p>"}}} />
+
+</CenterLayout>
+
+
+<!-- ##DOCS-SOURCER-START
+{
+  "sourcePlugin": "github-discussions",
+  "hash": "0cd7251ff5eb497a139a65d8fa4858ec"
+}
+##DOCS-SOURCER-END -->