fix: harden scheduled log write in app-test workflow to avoid non-fast-forward push failures

[Copilot]

Scheduled app-test runs were passing tests but intermittently failing in Log to File when pushing logs/run.md to master due to concurrent updates and stale local state. This change makes the log write path rebase-safe and serializes overlapping workflow runs. See https://github.com/adobe/aio-e2e-tests/actions

• Workflow-level run serialization

  • Added top-level concurrency to prevent overlapping scheduled runs from racing on the same file update.
  • Uses a stable group name and keeps cancel-in-progress: false.

• Rebase-safe log commit/push flow

  • Updated Log to File to sync with origin/master before committing.
  • Handles no-op updates without failing the job.
  • Pushes explicitly to origin master (HEAD:master) instead of relying on implicit defaults.

• Updated Log to File core sequence

  run: |
    set -euo pipefail
    git config user.name adobe-bot
    git config user.email grp-opensourceoffice@adobe.com
    git fetch origin master
    git checkout master
    git pull --rebase origin master
    echo "- $(date) Node ${{ matrix.node-version }} ..." >> logs/run.md
    git add logs/run.md
    git commit -m "generated" || echo "Nothing to commit"
    git push origin HEAD:master

Original prompt

Create a fix for the failing GitHub Actions job in this repository.

Context

• Repository: adobe/aio-e2e-tests
• Failing run/job URL: https://github.com/adobe/aio-e2e-tests/actions/runs/24643521691/job/72051741364
• Workflow file: .github/workflows/app-test.yml
• Failure: scheduled workflow run succeeds in tests but fails in step "Log to File" when pushing to master:
  • git push rejected with non-fast-forward ("fetch first") because remote master has new commits.

What to change

1. Update the "Log to File" step so it safely updates logs/run.md and pushes without non-fast-forward failures.
   • Fetch and pull/rebase from origin before committing.
   • Handle "nothing to commit" gracefully.
   • Push explicitly to origin master (or HEAD:master).
2. Add workflow-level concurrency to prevent overlapping scheduled runs from racing on pushing the same file.
   • Use a stable concurrency group name.
   • Do not cancel in-progress runs.

Acceptance criteria

• Scheduled runs should no longer fail due to git push non-fast-forward.
• Workflow should still run the matrix as before.
• Keep changes minimal and focused.

Notes

• Use best practices for git operations in CI.
• Ensure the checkout has sufficient permissions for push (do not change permissions unless required by repo settings).

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The job isn’t failing in the tests. The E2E test step completes successfully (PASS e2e/e2e.js). The failure happens afterward in the “Log to File” step when the workflow (on the scheduled run) tries to commit and push an update to logs/run.md:

! [rejected] master -> master (fetch first)
error: failed to push some refs ...
hint: Updates were rejected because the remote contains work that you do not have locally.

This is a classic non-fast-forward push rejection: another run (or another actor) updated master after this job checked out the repo, so the bot’s push is behind.

Fix (recommended): rebase/pull before pushing + retry on conflict

Update the “Log to File” step to pull/rebase the latest master before committing/pushing, and retry if necessary.

Replace the current “Log to File” step (lines 48–56 in .github/workflows/app-test.yml at ref c3c14ed927ebb879aa3a18b81d95fd5daee22242) with something like:

- name: Log to File
  if: ${{ always() && (github.event_name == 'schedule') }}
  run: |
    set -euo pipefail
    git config user.name adobe-bot
    git config user.email grp-opensourceoffice@adobe.com

    # Ensure we are up to date to avoid non-fast-forward push rejections
    git fetch origin master
    git checkout master
    git pull --rebase origin master

    echo "- $(date) Node ${{ matrix.node-version }} ${{ job.status == 'success' && 'success' || job.status }}" >> logs/run.md

    git add logs/run.md
    git commit -m "generated" || echo "Nothing to commit"
    git push origin HEAD:master

Why this works: it integrates any remote updates made since checkout, so your push becomes a fast-forward.

Fix (more robust): serialize schedule runs or write logs without pushing to master

If scheduled runs overlap (you have max-parallel: 1 only within the matrix job, not across workflow runs), two scheduled runs can still race to push. Add workflow-level concurrency to prevent simultaneous runs from both trying to push:

concurrency:
  group: aio-e2e-tests-scheduled-logger
  cancel-in-progress: false

Place that near the top of the workflow (same level as on: / jobs:). This reduces the chance of push conflicts dramatically.

Optional improvement: use a dedicated branch or artifact instead of committing to master

Committing from CI to master is inherently conflict-prone. If feasible, consider:

• pushing logs to a separate logs branch, or
• uploading a build artifact, or
• using GitHub Pages / issue comment / release notes, etc.

But the minimal change to get the job green is: pull/rebase before pushing (and optionally add concurrency).

User: fix it in a new PR

Assistant: I’ve kicked off creation of a new PR with the workflow changes (pull/rebase before pushing the log update, plus workflow-level concurrency) and I’m waiting for your confirmation in the dialog to proceed with applying and opening it.

This pull request was created from Copilot chat.