feat(RELEASE-1211): add push workflow so internal mirrors development

This commit adds a github workflow to push to the internal branch
whenever a push is made to the development branch. Thus, the internal
branch will mirror the development branch so internal can be used for
the app-sre cluster. It also modifies the promote_branch script to no
longer push to the internal branch and explains the PR process for the
internal directory in CONTRIBUTING.md.

Signed-off-by: Johnny Bieren <[email protected]>

.github/scripts/promote_branch.sh

@@ -97,9 +97,6 @@ if [ -z "${TARGET_BRANCH}" ]; then
 fi
 if [ "${TARGET_BRANCH}" == "staging" ]; then
     SOURCE_BRANCH="development"
-    # App sre restricts what branches we can consume from, so we create duplicate branches internal and stable
-    # to fit their regex requirements
-    SRE_DUPLICATE_BRANCH="internal"
 elif [ "${TARGET_BRANCH}" == "production" ]; then
     SOURCE_BRANCH="staging"
     SRE_DUPLICATE_BRANCH="stable"
@@ -156,7 +153,9 @@ fi
 
 git checkout $SOURCE_BRANCH
 git push origin $SOURCE_BRANCH:$TARGET_BRANCH
-git push origin $SOURCE_BRANCH:$SRE_DUPLICATE_BRANCH
+if [ ! -z "$SRE_DUPLICATE_BRANCH" ] ; then
+    git push origin $SOURCE_BRANCH:$SRE_DUPLICATE_BRANCH
+fi
 
 cd -
 rm -rf ${tmpDir}

.github/workflows/copy_development_to_internal.yaml

@@ -0,0 +1,28 @@
+---
+name: Update Internal Branch
+
+on:
+  push:
+    branches: [development]
+
+permissions: 
+  contents: write
+
+jobs:
+  sync:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Setup Git User
+        run: |
+          git config user.name "GitHub Action"
+          git config user.email "[email protected]"
+
+      - name: Update Internal Branch
+        run: |
+          git checkout -b internal
+          git push -f origin internal

CONTRIBUTING.md

@@ -83,6 +83,18 @@ Before a pull request can be merged:
 * The CI has to pass successfully
 * Every comment has to be addressed and resolved
 
+#### Pull Requests Only Updating the [internal Directory](internal)
+
+If the files changed for a pull request only contains things in the [internal](internal) directory, the E2E testing is irrelevant.
+This is because these resources need to be deployed to the staging cluster in order for E2E to use them, and we do not deploy resources from pull requests to that cluster.
+So, in this case, E2E tests are irrelevant and should be ignored.
+
+#### Pull Requests Updating the [internal Directory](internal) and Other Files
+
+If a pull request is updating both internal resources as well as other resources, the pull request should be split into two: one for the internal resources, one for the rest.
+The reason for this is that the internal resource pull request should be merged first. Then, the new resources will be present on the staging cluster. This allows the second
+pull request, with the other changes, to properly execute E2E with the aforementioned internal changes present on the staging cluster.
+
 ### Image References
 
 Most tasks in this repo use the release-service-utils image defined in [the release-service-utils repo](https://github.com/konflux-ci/release-service-utils).