feat(workflows): add devcontainer infrastructure change log workflow

[AhmedMustafa249]

Pull Request

Description

Adds devcontainer-change-log.yml, an informational GitHub Actions workflow that triggers on push to main or develop when devcontainer infrastructure files change. It outputs a structured markdown table to $GITHUB_STEP_SUMMARY categorizing each changed file by tier and pre-build impact.

Key behaviors:

• Handles workflow_dispatch with an informational message (no diff available)
• Guards against zero-SHA initial pushes
• Distinguishes a git diff failure (unreachable $BEFORE_SHA, e.g. after a force push) from a genuinely empty diff
• Categorizes files: on-create.sh (High), post-create.sh (Low), devcontainer.json (High), copilot-setup-steps.yml (Medium), other .devcontainer/* (Medium)

Related Issue(s)

Closes #517

Type of Change

Code & Documentation:

• Bug fix (non-breaking change fixing an issue)
• New feature (non-breaking change adding functionality)
• Breaking change (fix or feature causing existing functionality to change)
• Documentation update

Infrastructure & Configuration:

• GitHub Actions workflow
• Linting configuration (markdown, PowerShell, etc.)
• Security configuration
• DevContainer configuration
• Dependency update

Other:

• Script/automation (.ps1, .sh, .py)
• Other (please describe):

Testing

Verified end-to-end on a fork where main has no branch protection:

1. Saved the current main SHA: BEFORE=$(git rev-parse HEAD)
2. Merged log-devcontainer-infrastructure-changes-workflow into main and pushed to origin.
3. The push triggered the devcontainer-change-log workflow via the .devcontainer/** path filter.
4. Inspected the run via gh run view --web — the step summary rendered the expected markdown table with files categorized by tier and pre-build impact (e.g. devcontainer.json → Config / High, on-create.sh → Lifecycle Scripts / High).
5. Confirmed the workflow_dispatch branch message also displays correctly by triggering a manual run against the feature branch.
6. Reset main back to the pre-merge state: git reset --hard "$BEFORE" && git push --force origin main.

The workflow file, category logic, and error-handling paths all behaved as designed.

Checklist

Required Checks

• Documentation is updated (if applicable)
• Files follow existing naming conventions
• Changes are backwards compatible (if applicable)
• Tests added for new functionality (if applicable)

Required Automated Checks

The following validation commands must pass before merging:

• Markdown linting: npm run lint:md
• Spell checking: npm run spell-check
• Frontmatter validation: npm run lint:frontmatter
• Skill structure validation: npm run validate:skills
• Link validation: npm run lint:md-links
• PowerShell analysis: npm run lint:ps
• Plugin freshness: npm run plugin:generate
• YAML linting: npm run lint:yaml
• SHA consistency: npm run lint:version-consistency

Security Considerations

• This PR does not contain any sensitive or NDA information
• Any new dependencies have been reviewed for security issues
• Security-related scripts follow the principle of least privilege

The workflow uses permissions: contents: read at both workflow and job level. persist-credentials: false is set on the checkout step. No secrets or PATs are used. The single external action (actions/checkout) is pinned to a full commit SHA with a version comment.

Additional Notes

The workflow is purely informational, it writes only to $GITHUB_STEP_SUMMARY and has no write permissions against the repository. It is safe to ignore if the run is skipped or cancelled.

[katriendg]

@AhmedMustafa249 — thanks so much for picking this up!!
The workflow logic looks really good.

Just a couple of small things before we can merge:

1. Documentation update needed

I have just updated the related issue #517 to reflect an omission we had: docs updates. Just realized this now...

docs/architecture/workflows.md has a Workflow Inventory table that lists every workflow in the repo. The new devcontainer-change-log.yml isn't in it yet, and the checklist has "Documentation is updated" ticked. Could you add a row there?

Something like:

| devcontainer-change-log.yml | Push to main/develop | Logs devcontainer infrastructure file changes to the step summary |

2. Two linting checks worth running and ticking off

The checklist is missing a couple of validations that the lint:all chain includes and that apply directly to a new workflow file:

• npm run lint:yaml — validates the YAML syntax of the new workflow file
• npm run lint:version-consistency — checks that the actions/checkout SHA is consistent with the rest of the repo

Both should be quick passes given the file looks correct, but worth confirming and adding to the checklist so reviewers can see they were verified.

Once those are in, this should be good to go!

[AhmedMustafa249]

@katriendg Added the workflow inventory item to the workflow documentation, the two extra test for YAML linting and SHA version consistency already passed before but I overlook adding them to the automated checks list -- Everything should be all good!

[katriendg]

Thanks @AhmedMustafa249!

I also realize the issue had an optional item in original issue Optionally notify via issue comment when changes affect prebuild-critical files. @WilliamBerryiii > what is your view on adding this? It will require adding Issues or PR write permission which I'm not sure you also want to add, and how to define critical files list first? But without it the PR may not completely align to the Issue.
Thoughts?

[WilliamBerryiii]

Thanks for this contribution, @AhmedMustafa249! Great work putting together the devcontainer change log workflow. 🎉

I pushed a small addition to your branch — two new case patterns so the workflow also categorizes base image and features changes, which were called out in the acceptance criteria on #517:

.devcontainer/Dockerfile*|.devcontainer/*.dockerfile)
  echo "| \`$file\` | Base Image | High |"
  ;;
.devcontainer/features/*)
  echo "| \`$file\` | Features | Medium |"
  ;;

This ensures all four categories (base image, features, lifecycle scripts, setup steps) have explicit patterns before the catch-all.

[WilliamBerryiii]

Thanks @AhmedMustafa249!

I also realize the issue had an optional item in original issue Optionally notify via issue comment when changes affect prebuild-critical files. @WilliamBerryiii > what is your view on adding this? It will require adding Issues or PR write permission which I'm not sure you also want to add, and how to define critical files list first? But without it the PR may not completely align to the Issue. Thoughts?

I'm ok skipping this. The issue was primarily set up for alerting me on when the codespace needed to be rebuilt ... but I automated all of that, so no need for the automated issue publishing.