Conversation
- Restructure root README for multi-image project architecture - Complete rewrite of PlatformIO image README from scratch - Remove misleading claims about pre-cached toolchains - Add comprehensive usage examples (CI/CD, local dev) - Include detailed troubleshooting section - Document design decisions and rationale - Clarify that toolchains download on first build - Add version information table - Improve structure and readability throughout
- project-structure.mdc: Always-applied rule defining multi-image architecture - documentation-standards.mdc: Guidelines for README files (root and image-specific) - dockerfile-standards.mdc: Conventions for Dockerfile creation and optimization - adding-new-images.mdc: Complete checklist for adding new Docker images - commit-conventions.mdc: Git commit message standards and best practices These rules ensure consistency across the project and guide future development.
- Add 🐳 Docker whale to workflow name for better visibility - Add step icons for improved readability: - 📥 Checkout repository - 🔧 Set up Docker Buildx - 🔐 Log in to Registry - 🏷️ Extract metadata - 🎯 Generate tags - 💾 Determine cache strategy - 🐳 Build and push Docker image - 📝 Install Cosign - ✍️ Sign Docker image Improves visual scanning and gives workflow a modern, professional appearance.
- Define emoji icon conventions for workflow names - Provide comprehensive icon reference for common step types - Include practical examples and benefits - Ensure consistency across all workflow files - Auto-applies to all .yml/.yaml files in .github/workflows/ This rule will help maintain visual consistency and readability in GitHub Actions workflows as the project grows.
- Explicitly disallow AI from committing changes automatically - AI can suggest commit messages but requires user confirmation - AI can propose what to commit but user must approve - Ensures developer maintains full control over commit history
- Emphasize Dockerfile-first approach - Require local build before documentation - Add warning to never document before successful build - Restructure as step-by-step workflow
- Simplify workflow steps for adding new Docker images - Emphasize the importance of building the image before documentation - Update README requirements to include essential sections - Streamline Dockerfile and README creation guidelines - Enhance testing and verification checklist for new images
…tion - Set 'alwaysApply: true' for guidelines on adding new images, commit conventions, Dockerfile standards, documentation standards, and GitHub Actions standards - Ensures uniform application of rules across relevant files
- Create reusable Docker build workflow for all images - Refactor platformio.yml to use reusable workflow (141 -> 45 lines) - Support custom_tags (plural) with comma-separated values - Add .actrc configuration for local workflow testing - Update .gitignore with act-related files and better organization - Update Cursor rules to document reusable workflow pattern - Add local testing guidelines with act to documentation standards
- Remove sections on Troubleshooting and Design Decisions from documentation standards to maintain focus on usage. - Update PlatformIO README to eliminate troubleshooting content, emphasizing reliance on upstream documentation. - Streamline version information presentation for improved clarity.
- Introduced a new input parameter 'build_args' for specifying build arguments in the reusable Docker build workflow. - This allows users to pass multiple build arguments in a newline-separated format, enhancing flexibility in Docker image builds.
- Introduced a new Docker image for ESP-IDF 5.4.1, including QEMU support and comprehensive testing tools. - Created a GitHub Actions workflow for building the ESP-IDF Docker image, allowing for automated builds on push and pull request events. - Updated README with detailed usage instructions, supported chips, and quick start guide for the ESP-IDF image. - Added Dockerfile for the ESP-IDF image, including necessary dependencies and configuration for testing and code quality tools.
…treamlined ESP-IDF development environment.
There was a problem hiding this comment.
Pull Request Overview
This pull request transforms the repository into a comprehensive multi-image Docker development environment with standardized workflows, documentation, and CI/CD automation. The main focus is adding ESP-IDF support alongside existing PlatformIO capabilities, while establishing clear standards and reusable workflows for future image additions.
Key Changes:
- Added reusable GitHub Actions workflow for Docker builds with standardized tagging, caching, and signing
- Introduced ESP-IDF 5.4.1 image with QEMU emulation and comprehensive testing tools
- Established comprehensive documentation and coding standards via Cursor rules
- Cleaned up obsolete Replit configuration files
Reviewed Changes
Copilot reviewed 16 out of 17 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/reusable-docker-build.yml |
New reusable workflow providing standardized Docker build pipeline with multi-arch support, dynamic tagging, and Cosign signing |
.github/workflows/esp-idf.yml |
Workflow for ESP-IDF image builds using the reusable workflow |
.github/workflows/platformio.yml |
Refactored to use reusable workflow, eliminating code duplication |
images/esp-idf/Dockerfile |
New ESP-IDF 5.4.1 image with QEMU, pytest, and testing frameworks |
images/esp-idf/README.md |
Comprehensive documentation for ESP-IDF image |
images/platformio/README.md |
Enhanced documentation with detailed usage examples and version info |
README.md |
Updated to support multi-image architecture with generic overview |
.cursor/rules/*.mdc |
New standards documents for Dockerfiles, workflows, documentation, and commits |
.actrc |
Configuration for local workflow testing with act |
.replit, replit.md |
Removed obsolete Replit configuration |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+31
to
+33
| # Create ccache directory that's writable by any user | ||
| RUN mkdir -p /opt/ccache && \ | ||
| chmod 1777 /opt/ccache |
There was a problem hiding this comment.
Setting permissions to 1777 (world-writable with sticky bit) on /opt/ccache could pose a security risk. While the sticky bit prevents users from deleting others' files, this allows any user to write to this directory. Consider using a more restrictive permission model or documenting the security implications.
Suggested change
| # Create ccache directory that's writable by any user | |
| RUN mkdir -p /opt/ccache && \ | |
| chmod 1777 /opt/ccache | |
| # Create ccache directory with restricted permissions (owner: root, group: root) | |
| RUN mkdir -p /opt/ccache && \ | |
| chown root:root /opt/ccache && \ | |
| chmod 0770 /opt/ccache |
…de image scope for better caching management
…er branch - Modify the logic for adding the ESP-IDF version tag to ensure it is only included when the workflow is triggered on the master branch. - Adjust handling of custom tags to maintain flexibility in tagging based on branch context.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a comprehensive set of standards, automation, and documentation improvements for managing Docker images and CI/CD workflows in the repository. The main changes include the addition of reusable GitHub Actions workflows for Docker builds, standardization of workflow and Dockerfile practices, and the introduction of detailed documentation and project structure conventions. These updates streamline the process for adding new images, ensure consistency, and make local and CI/CD testing easier.
CI/CD Workflow Automation and Standardization
.github/workflows/reusable-docker-build.yml) for Docker image builds, supporting dynamic tagging, cache strategy, multi-architecture builds, and image signing. This workflow is now used by per-image workflows likeplatformio.ymland the newesp-idf.yml, greatly simplifying and standardizing CI/CD for all images. [1] [2] [3] [4]esp-idf.yml) and refactored the PlatformIO workflow to use the new reusable workflow, improving maintainability and consistency. [1] [2] [3].actrcconfiguration for local workflow testing withact, enabling developers to test CI workflows locally with consistent container options and verbose output.Repository, Dockerfile, and Workflow Standards
dockerfile-standards.mdc), GitHub Actions workflows (github-actions-standards.mdc), documentation (documentation-standards.mdc), and commit conventions (commit-conventions.mdc). These documents set clear expectations for image structure, build arguments, environment variables, workflow naming, and commit practices. [1] [2] [3] [4]project-structure.mdc) outlining directory layout, registry naming, and branch strategy for the multi-image Docker project.Documentation and Contribution Process
Cleanup
.replitconfiguration, as it is no longer needed for the current development workflow.These changes collectively make the repository more maintainable, scalable, and contributor-friendly, while ensuring high-quality, consistent Docker images and CI/CD processes.