CONTRIBUTING.md

@@ -27,8 +27,8 @@ Thank you for your interest in contributing to this project! We appreciate your
    git push origin feature-branch-name
    ```
 
-3. Open a PR on GitHub, describing your changes clearly.
-4. If your PR is related to an issue, use the [GitHub key words](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). 
+3. Open a PR on StackitGit, describing your changes clearly.
+4. If your PR is related to an issue, use the [StackitGit key words](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). 
 This will ensure that the related issue will automatically close when your change is merged.
 5. Address any feedback and update your PR as necessary.
 

README.md

@@ -55,7 +55,7 @@ steps:
 
 > [!Note]
 > 1. If You are using issue-body-file-path then please make sure the file is reachable; for example, if the file is in your repo, then please checkout to your repo in the same job as the approval issue.
-> 2. When using issue-body, the content string is passed as an arguent which is limited by github at 10kb. For content >= 10kb, use files for passing the issue body. 
+> 2. When using issue-body, the content string is passed as an arguent which is limited by StackitGit at 10kb. For content >= 10kb, use files for passing the issue body. 
 
 > [!CAUTION]
 > When using a file please make sure that the file size remains under 125 KB (a safe limit, to stay under the threshold). If the file size is huge, then the file content will be broken into multiple chunks, each representing an issue comment. With this many API requests the API rate limit is exceeded, and the actions will be temporarily blocked, resulting in an error message like: `403 You have exceeded a secondary rate limit and have been temporarily blocked from content creation. Please retry your request again later.`
@@ -95,7 +95,7 @@ For a seamless experience, it is recommended that you add the custom words to a
 
 ## Org team approver
 
-If you want to have `approvers` set to an org team, then you need to take a different approach. The default [StackitGit Actions automatic token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) does not have the necessary permissions to list out team members. If you would like to use this, then you need to generate a token from a StackitGit App with the correct set of permissions. Apart from this, the GH app will also need the Issue: Read & Write role.
+If you want to have `approvers` set to an org team, then you need to take a different approach. The default [StackitGit Actions automatic token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) does not have the necessary permissions to list out team members. If you would like to use this, then you need to generate a token from a StackitGit App with the correct set of permissions. Apart from this, the StackitGit app will also need the Issue: Read & Write role.
 
 Create an Organization StackitGit App with **read-only access to organization members**. Once the app is created, add a repo secret with the app ID. In the StackitGit App settings, generate a private key and add that as a secret in the repo as well. You can get the app token by using the [`actions/create-github-app-token`](https://github.com/actions/create-github-app-token) StackitGit Action:
 

action.yaml

@@ -47,7 +47,7 @@ inputs:
     required: false
     default: "true"
   polling-interval-seconds:
-    description: Number of seconds to wait between polling GitHub API for approval status
+    description: Number of seconds to wait between polling StackitGit API for approval status
     required: false
     default: "10"
 outputs:

main.go

@@ -14,7 +14,7 @@ import (
 
 // patchIssueState closes or otherwise updates an issue's state without decoding
 // the response body into a github.Issue. go-github's Issues.Edit decodes the
-// response into github.Issue, which fails against Forgejo because its issue
+// response into github.Issue, which fails against StackitGit because its issue
 // response embeds "repository.owner" as a plain string rather than a User object.
 func patchIssueState(_ context.Context, client *forgejo.Client, owner, repo string, number int, state string) error {
 	issueState := forgejo.StateType(state)
@@ -125,12 +125,12 @@ func newForgejoClient() (*forgejo.Client, error) {
 	token := os.Getenv(envVarToken)
 	serverUrl := os.Getenv("GITHUB_SERVER_URL")
 	if serverUrl == "" {
-		return nil, fmt.Errorf("GITHUB_SERVER_URL must be set for Forgejo client")
+		return nil, fmt.Errorf("GITHUB_SERVER_URL must be set for StackitGit client")
 	}
 
 	client, err := forgejo.NewClient(serverUrl, forgejo.SetToken(token))
 	if err != nil {
-		return nil, fmt.Errorf("failed to create forgejo client: %w", err)
+		return nil, fmt.Errorf("failed to create StackitGit client: %w", err)
 	}
 	return client, nil
 }
@@ -189,7 +189,7 @@ func main() {
 	ctx := context.Background()
 	forgejoClient, err := newForgejoClient()
 	if err != nil {
-		fmt.Printf("error connecting to forgejo server: %v\n", err)
+		fmt.Printf("error connecting to StackitGit server: %v\n", err)
 		os.Exit(1)
 	}
 

workflow_dispatcher.md

@@ -1,4 +1,4 @@
-# Forgejo Actions: Manual Approvals Guide
+# StackitGit Actions: Manual Approvals Guide
 
 While StackitGit Actions does not currently feature native environment protection rules that pause a running workflow for a UI approval, the most effective and resource-efficient workaround is to split your CI/CD pipeline into separate workflows using the `workflow_dispatch` event.
 
@@ -27,7 +27,7 @@ jobs:
 
 ## Step 2: The Manual Deployment Workflow
 
-Create a second workflow triggered *only* by `workflow_dispatch`. This generates a "Run Workflow" button in the Forgejo UI, serving as your manual approval gate.
+Create a second workflow triggered *only* by `workflow_dispatch`. This generates a "Run Workflow" button in the StackitGit UI, serving as your manual approval gate.
 
 ```yaml
 name: 2. Manual Production Deploy
@@ -54,4 +54,4 @@ jobs:
 
 1. A developer pushes code, triggering the **Build and Test** workflow automatically.
 2. The team reviews the workflow results and test logs. The runner completes its job, reports success, and shuts down.
-3. When the release is approved, an authorized team member navigates to the Forgejo Actions tab, selects the **Manual Production Deploy** workflow, and clicks "Run Workflow".
+3. When the release is approved, an authorized team member navigates to the StackitGit Actions tab, selects the **Manual Production Deploy** workflow, and clicks "Run Workflow".