More work on actions

.github/actions/deploy-to-control-plane/action.yml

@@ -17,6 +17,12 @@ inputs:
     description: 'Timeout in seconds for waiting for workloads to be ready'
     required: false
     default: '900'
+  cpln_token:
+    description: 'Control Plane token'
+    required: true
+  pr_number:
+    description: 'Pull Request number'
+    required: true
 
 outputs:
   review_app_url:
@@ -50,11 +56,14 @@ runs:
       run: ${{ github.action_path }}/scripts/get-commit-sha.sh
       env:
         GITHUB_TOKEN: ${{ inputs.github_token }}
-        PR_NUMBER: ${{ env.PR_NUMBER }}
+        PR_NUMBER: ${{ inputs.pr_number }}
 
     - name: Deploy to Control Plane
       id: deploy
       shell: bash
+      env:
+        CPLN_TOKEN: ${{ inputs.cpln_token }}
+        PR_NUMBER: ${{ inputs.pr_number }}
       run: |
         echo "🚀 Deploying app for PR #${PR_NUMBER}..."
 

.github/actions/help-command/action.yml

@@ -5,12 +5,15 @@ inputs:
   github-token:
     description: 'GitHub token for posting comments'
     required: true
+  issue-number:
+    description: 'PR/Issue number to post the comment to (optional, defaults to event context)'
+    required: false
 
 runs:
   using: "composite"
   steps:
     - name: Show Available Commands
-      uses: actions/github-script
+      uses: actions/github-script@v7
       with:
         github-token: ${{ inputs.github-token }}
         script: |
@@ -80,12 +83,14 @@ runs:
             '3. Open an issue in this repository',
           ].join('\n');
 
-          const context = github.context;
-          if (context.eventName === 'issue_comment') {
+          const issueNumber = inputs['issue-number'] || 
+            (context.eventName === 'issue_comment' ? context.payload.issue.number : null);
+
+          if (issueNumber) {
             await github.rest.issues.createComment({
               owner: context.repo.owner,
               repo: context.repo.repo,
-              issue_number: context.payload.issue.number,
+              issue_number: issueNumber,
               body: helpText
             });
           } else {

.github/readme.md

@@ -0,0 +1,85 @@
+# Developing and Testing Github Actions
+
+Testing Github Actions on an existing repository is tricky.
+
+The main issue boils down to the fact that Github Actions uses the workflow files in the branch where the event originates. This is fine for push events, but it becomes a problem when you want to test workflows that are triggered by comments on a pull request.
+
+Here's a summary of the behavior:
+
+Behavior of push and pull_request Events
+	1.	Push on a Branch:
+	•	When you push changes to a branch (e.g., feature-branch), GitHub Actions uses the workflow files in that same branch.
+	•	This is why changes to workflows work seamlessly when testing with push events.
+	2.	Pull Request Events:
+	•	For pull_request events (e.g., a PR from feature-branch into master), GitHub Actions will always use the workflow files from the target branch (e.g., master), not the source branch (e.g., feature-branch).
+	•	This is a security feature to prevent someone from introducing malicious code in a PR that modifies the workflow files themselves.
+
+Impact on Comment-Triggered Workflows
+
+When you want to trigger workflows via comments (issue_comment) in a pull request:
+	•	The workflow code used will always come from the master branch (or the default branch), regardless of the branch where the PR originates.
+	•	This means the PR’s changes to the workflow won’t be used, and the action invoked by the comment will also use code from master.
+
+Workarounds to Test Comment-Triggered Workflows
+
+If you want to test workflows in a way that uses the changes in the pull request, here are your options:
+
+1. Use Push Events for Testing
+	•	Test your changes on a branch with push triggers.
+	•	Use workflow_dispatch to simulate the events you need (like invoking actions via comments).
+
+This allows you to confirm that your changes to the workflow file or actions behave as expected before merging into master.
+
+2. Merge the Workflow to master Temporarily
+
+If you absolutely need the workflow to run as part of a pull_request event:
+	1.	Merge your workflow changes into master temporarily.
+	2.	Open a PR to test your comment-triggered workflows.
+	3.	Revert the changes in master if necessary.
+
+This ensures the workflow changes are active in master while still testing with the pull_request context.
+
+3. Add Logic to Detect the Source Branch
+
+Use github.event.pull_request.head.ref to add custom logic in your workflow that behaves differently based on the source branch.
+	•	Example:
+
+jobs:
+  test-pr:
+    runs-on: ubuntu-latest
+    if: ${{ github.event.pull_request.head.ref == 'feature-branch' }}
+    steps:
+      - name: Checkout Code
+        uses: actions/checkout@v3
+
+      - name: Debug
+        run: echo "Testing workflow changes in feature-branch"
+
+However, this still requires the workflow itself to exist in master.
+
+4. Use a Fork or a Temporary Repo
+
+Create a temporary repository or a fork to test workflows in isolation:
+	•	Push your workflow changes to master in the test repository.
+	•	Open a PR in the fork to test how workflows behave with issue_comment events and PR contexts.
+
+Once confirmed, you can replicate the changes in your main repository.
+
+6. Alternative Approach: Split Workflows
+
+If your workflow includes comment-based triggers (issue_comment), consider splitting your workflows:
+	•	A base workflow in master that handles triggering.
+	•	A test-specific workflow for validating changes on a branch.
+
+For example:
+	1.	The base workflow triggers when a comment like /run-tests is added.
+	2.	The test-specific workflow runs in response to the base workflow but uses the branch’s code.
+
+Summary
+	•	For push events: The branch-specific workflow is used, so testing changes is easy.
+	•	For pull_request and issue_comment events: GitHub always uses workflows from the master branch, and there’s no direct way to bypass this.
+
+To test comment-triggered workflows:
+	1.	Use push or workflow_dispatch to validate changes.
+	2.	Merge workflow changes temporarily into master to test with pull_request events.
+	3.	Use tools like act for local simulation.