Wmlynik/v3.2.1 ci #1368
Wmlynik/v3.2.1 ci #1368
Conversation
* phoenix-rtos-tests 2b4af5d...b2d738a (1): > trunner: automatically find port for armv7m7 targets
* plo f708624...a5ab330 (1): > flash-imxrt: Support W25Q512NW-IQ/IN flash chips
Done in the same way as the rootfs to avoid loosing permissions when packing to zip. This small issue hasn't been seen before, because in CI binaries like phoenixd/psu are taken from docker. JIRA: CI-575
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @wmlynik, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request updates the continuous integration (CI) pipeline configurations and various Git submodules. The changes primarily involve aligning the build and runner actions with specific "v3.2.1" Docker image tags and updating core project submodules to their latest respective commits. This ensures the CI environment and dependencies are consistent with the intended "v3.2.1" version.
Highlights
- Updated Phoenix Build Action Docker Image: The GitHub Action for building Phoenix RTOS was updated to use the Docker image "phoenixrtos/build:v3.2.1".
- Updated Phoenix Runner Action Docker Image: The GitHub Action for running Phoenix RTOS tests was updated to use the Docker image "phoenixrtos/devel:v3.2.1".
- Synchronized Git Submodules: Several core project Git submodules, including "phoenix-rtos-build", "phoenix-rtos-devices", "phoenix-rtos-tests", and "plo", were synchronized to their latest specified commit hashes.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request updates the CI configuration to use specific versions of Docker images and updates several submodules. Pinning the Docker image versions in the GitHub Actions (phoenix-build and phoenix-runner) to v3.2.1 is a good practice that improves the reliability and reproducibility of the CI process.
My review includes suggestions to further improve maintainability by using action inputs for the version tag, which would centralize the version configuration and make future updates easier.
The submodule commits have also been updated, presumably to align with the v3.2.1 release. The pull request description was not filled out, which would have been helpful to provide more context for these changes.
| runs: | ||
| using: 'docker' | ||
| image: 'phoenixrtos/build' | ||
| image: 'phoenixrtos/build:v3.2.1' |
There was a problem hiding this comment.
Pinning the Docker image version is a great practice for ensuring reproducible builds. To improve maintainability and make it easier to update this version in the future, consider defining the version tag as an input for this action. This would avoid hardcoding the version string and allow it to be managed from a single place in the workflow that calls this action.
For example, you could add an input like this:
inputs:
image-tag:
description: 'Tag for the phoenixrtos/build docker image'
required: true
default: 'v3.2.1'And then use it here:
image: 'phoenixrtos/build:${{ inputs.image-tag }}'
| runs: | ||
| using: 'docker' | ||
| image: 'phoenixrtos/devel' | ||
| image: 'phoenixrtos/devel:v3.2.1' |
There was a problem hiding this comment.
Similar to the phoenix-build action, pinning the Docker image version is a good improvement. To make this more maintainable, consider parameterizing the version tag using an action input. This centralizes the version number, making future updates easier.
For example, you could add an input:
inputs:
image-tag:
description: 'Tag for the phoenixrtos/devel docker image'
required: true
default: 'v3.2.1'And then reference it in the image definition:
image: 'phoenixrtos/devel:${{ inputs.image-tag }}'
Unit Test Results 1 files 1 554 suites 1h 56m 44s ⏱️ Results for commit 52c377c. ♻️ This comment has been updated with latest results. |
Description
Motivation and Context
Types of changes
How Has This Been Tested?
Checklist:
Special treatment