Auto update, build, and publish image #19
Conversation
|
Connected to Huly®: GHALL-313 |
WalkthroughThis pull request introduces two new GitHub Actions workflows in the repository. One workflow automates the process of building, versioning, and pushing a Docker image on a weekly schedule and via manual dispatch. The other workflow updates the Docker Hub repository description when changes are detected in the README file on the main branch. Both workflows utilize environment variables and GitHub secrets for authentication and configuration. Changes
Sequence Diagram(s)sequenceDiagram
participant Trigger as Scheduler/Manual
participant GHAction as GitHub Actions
participant Repo as Repository Checkout
participant Docker as DockerHub
participant Jotta as Jottacloud Repository
participant Build as Build & Push Process
Trigger->>GHAction: Trigger workflow (schedule/manual)
GHAction->>Repo: Checkout repository
GHAction->>Docker: Log in using secrets
GHAction->>Jotta: Add repo & fetch jotta-cli version
GHAction->>GHAction: Retrieve current Docker image version and compare
GHAction->>Build: Set up QEMU & Buildx, build multi-arch image
Build->>Docker: Push Docker image
GHAction->>Repo: Tag Git version and push tag
sequenceDiagram
participant Commit as Git Commit
participant GHAction as GitHub Actions
participant Docker as DockerHub
Commit->>GHAction: Push changes to README.md (on main)
GHAction->>Docker: Run dockerhub-description action
Docker->>GHAction: Update Docker Hub description
Poem
Tip 🌐 Web search-backed reviews and chat
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (4)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
❌ Changes requested. Reviewed everything up to 1f5fd33 in 1 minute and 14 seconds
More details
- Looked at
130lines of code in2files - Skipped
0files when reviewing. - Skipped posting
3drafted comments based on config settings.
1. .github/workflows/publish-image.yaml:11
- Draft comment:
Using '||' for default value may not work as expected. Consider using GitHub Actions’ conditional expressions to assign a default value. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
GitHub Actions does support '||' operator in expressions, but it's true that it can sometimes behave unexpectedly, especially with empty strings vs undefined values. However, in this case, both secrets.DOCKER_REPO and github.repository are well-defined variables in the GitHub Actions context. github.repository will always have a value, making this a safe usage.
The comment might be pointing to a real issue - empty strings could potentially cause problems with the || operator in some GitHub Actions contexts.
While the concern is valid in general, this specific usage is safe because github.repository is guaranteed to have a value, making it a reliable fallback.
The comment should be deleted because this is a safe and common pattern in GitHub Actions, and the fallback is guaranteed to work in this specific case.
2. .github/workflows/update-dockerhub-readme.yaml:18
- Draft comment:
The 'repository' field uses github.repository directly. For consistency with the publish workflow, consider using the same DOCKER_REPO value or secret if the DockerHub repo differs. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
- This is a new file, so the change is definitely in scope. 2. The comment references another workflow file I can't see. 3. github.repository is a valid GitHub context variable that provides the repository name. 4. Without seeing the other workflow, I can't verify if this consistency suggestion is valid. 5. The current approach using github.repository is technically correct.
I might be missing important context from the other workflow file that could make this consistency suggestion more important than I think.
Even if there is another workflow doing things differently, the current approach is valid and working. Making changes for pure consistency without clear benefits isn't a strong enough reason to keep the comment.
Delete this comment because it's speculative about consistency with unseen code, and the current implementation is technically correct.
3. .github/workflows/update-dockerhub-readme.yaml:18
- Draft comment:
The Docker Hub 'repository' is set to '${{ github.repository }}'. If the Docker Hub repo differs from the GitHub repo, consider parameterizing it (as done with DOCKER_REPO in the build workflow) to avoid mismatches. - Reason this comment was not posted:
Marked as duplicate.
Workflow ID: wflow_UljF40vvF2u89tUa
Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
.github/workflows/update-dockerhub-readme.yaml (2)
16-20: Action Inputs Are Sufficient with a Good Opportunity for Enhancement.
The inputs provided—username,password,repository,readme-filepath, andshort-description—are correctly configured to update the Docker Hub repository description.Consider the following improvement for enhanced flexibility:
If the user has configured the optional secretDOCKER_REPO(to override the repository when it differs from GitHub’s default), you might update the repository input to use it when available. For example:- repository: ${{ github.repository }} + repository: ${{ secrets.DOCKER_REPO != '' ? secrets.DOCKER_REPO : github.repository }}This change ensures that if
DOCKER_REPOis provided, it takes precedence.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 20-20: no new line character at the end of file
(new-line-at-end-of-file)
20-20: Ensure File Ends with a Newline.
Static analysis indicates that there is no newline character at the end of the file. Please add a newline at the end to adhere to best practices and YAML lint guidelines. For instance:- short-description: ${{ github.event.repository.description }} \ No newline at end of file + short-description: ${{ github.event.repository.description }} +🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 20-20: no new line character at the end of file
(new-line-at-end-of-file)
.github/workflows/publish-image.yaml (2)
48-55: Retrieving Latest Docker Image VersionThe command to pull tag names from Docker Hub and exclude the "latest" tag is a clever solution.
- Using
jq,grep,awk, andsorthelps extract the desired version.
Be mindful that tag formats on Docker Hub must remain consistent for this pipeline to work. It may be useful to add error handling in caseDOCKER_VERSIONends up empty.
96-96: File Ending NewlineThe static analysis tool flagged that the file is missing a newline at the end. Please add a newline character at the end of the file to adhere to best practices and style guidelines.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 96-96: no new line character at the end of file
(new-line-at-end-of-file)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/publish-image.yaml(1 hunks).github/workflows/update-dockerhub-readme.yaml(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.35.1)
.github/workflows/update-dockerhub-readme.yaml
[error] 20-20: no new line character at the end of file
(new-line-at-end-of-file)
.github/workflows/publish-image.yaml
[error] 96-96: no new line character at the end of file
(new-line-at-end-of-file)
🔇 Additional comments (16)
.github/workflows/update-dockerhub-readme.yaml (3)
1-8: Workflow Trigger Configuration Looks Correct.
The workflow is set to trigger on pushes to themainbranch and only when theREADME.mdfile changes, which aligns with the PR objectives.
9-12: Job Setup is Configured Properly.
Theupdate_readmejob is correctly defined to run onubuntu-latest, ensuring a current environment for executing the step.
13-15: Step Definition is Clear and Accurate.
The step named "Docker Hub Description" utilizes thepeter-evans/dockerhub-description@v3action as intended. All required keys are introduced starting with thewith:block..github/workflows/publish-image.yaml (13)
1-2: Descriptive Workflow NameThe workflow name is clear and descriptive, indicating its purpose to build and push the Docker image.
3-7: Correct Trigger ConfigurationThe schedule and manual dispatch triggers are configured correctly. The cron expression is clear, and having both automated and manual triggers provides flexibility.
8-12: Environment Variable FallbackThe
DOCKER_REPOenvironment variable is set with a fallback togithub.repositoryif the secret is not provided. Verify that the GitHub Actions expression syntax using||works as intended in your context.
13-16: Job Configuration is ClearThe job
buildis properly configured to run onubuntu-latest, which is appropriate for Docker operations.
17-21: Repository Checkout StepUsing
actions/checkout@v4ensures that the repository is properly checked out. No issues here.
22-28: DockerHub Login StepThe DockerHub login action is correctly implemented using the provided secrets. Ensure that the secrets
DOCKERHUB_USERNAMEandDOCKERHUB_TOKENare correctly configured in your repository settings.
29-37: Adding the Jottacloud RepositoryThe step to add the Jottacloud repository is well structured with
set -eto fail on errors.
- The public key is fetched using curl and the repository is added via a tee command.
- The apt-get update commands before and after adding the repository ensure that package lists are refreshed.
Consider verifying whether any additional packages (likeapt-transport-https) are needed for this repository on your target systems.
38-47: Fetching the Latest jotta-cli VersionThe logic to assign the latest version of jotta-cli using
apt-cache madison, sorting, and tailing works well.
- The conditional check for an empty version and subsequent exit is a good safety measure.
You might also consider outputting errors to stderr for clarity.
56-65: Version Comparison and Early ExitThe version comparison step is straightforward, ensuring that the build only proceeds when an update is needed.
- If semantic versioning is in use, ensure that string equality is sufficient, or consider a more robust version comparison if needed.
66-73: Setting up QEMU and BuildxBoth the QEMU setup and Buildx steps are correctly implemented, ensuring multi-platform builds. Their versions are up to date.
74-79: Setting the Date Variable for TaggingUsing the date in the
yyyyMMddformat to tag the image adds valuable contextual information to the build. The implementation is concise and effective.
80-88: Docker Image Build and PushThis step builds the Docker image for multiple platforms and applies both a
latesttag and a version-and-date tag.
- The use of Docker Buildx supports multi-platform builds effectively.
Consider verifying that the image tagging follows your versioning conventions, and possibly look into adding build caching if build times become an issue.
89-96: Git Tagging and PushTagging the Git repository with the new image version is a useful addition for traceability.
- The configuration of global Git user settings based on the GitHub actor is neat.
Ensure that the process handles potential tag conflicts gracefully if a tag already exists.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 96-96: no new line character at the end of file
(new-line-at-end-of-file)
add no update check, like the code-review bot recommended
* added check and throw error if docker version var is empty. * added newline to end of file, like review bot mentioned
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.github/workflows/update-dockerhub-readme.yaml (1)
13-15: Remove Trailing WhitespaceThere is trailing whitespace detected on line 15. Removing these extra spaces will help adhere to YAML linting guidelines and maintain a clean code style.
Suggested Diff:
- - name: Checkout repo - uses: actions/checkout@v4 - + - name: Checkout repo + uses: actions/checkout@v4🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 15-15: trailing spaces
(trailing-spaces)
.github/workflows/publish-image.yaml (1)
48-60: Retrieving Latest Docker Image Version
The step fetches the published Docker image versions from Docker Hub, filters out the "latest" tag, and extracts the version component correctly.
Please remove the trailing spaces on line 59 to adhere to YAML formatting guidelines.[static_analysis]
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 59-59: trailing spaces
(trailing-spaces)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/publish-image.yaml(1 hunks).github/workflows/update-dockerhub-readme.yaml(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.35.1)
.github/workflows/update-dockerhub-readme.yaml
[error] 15-15: trailing spaces
(trailing-spaces)
.github/workflows/publish-image.yaml
[error] 59-59: trailing spaces
(trailing-spaces)
🔇 Additional comments (15)
.github/workflows/update-dockerhub-readme.yaml (2)
1-8: Workflow Trigger Configuration Looks GoodThe trigger is correctly set to run on pushes to the
mainbranch when theREADME.mdfile is changed. This ensures that Docker Hub’s repository description stays in sync with repository updates on GitHub.
16-23: Docker Hub Description Step is Configured ProperlyThe step leveraging the
peter-evans/dockerhub-description@v4action is set up correctly. It makes proper use of the required secrets (DOCKERHUB_USERNAMEandDOCKERHUB_TOKEN) and smartly falls back togithub.repositorywhenDOCKER_REPOisn’t set. Additionally, passing./README.mdas the readme filepath and using the repository description for a short description aligns well with the intended functionality..github/workflows/publish-image.yaml (13)
1-2: Workflow Name is Clearly Defined
The workflow name "Build and Push Docker Image" clearly communicates the purpose of the action.
3-7: Defined Triggers for Scheduled and Manual Dispatch
The workflow is configured to run every Sunday at midnight UTC and also supports manual dispatch, which provides flexibility in execution.
8-12: Environment Variable Configuration
DefiningDOCKER_REPOas${{ secrets.DOCKER_REPO || github.repository }}offers a convenient default to the GitHub repository name while allowing it to be overridden via secrets. Please verify that the logical OR expression works as expected in the GitHub Actions context.
13-21: Job and Checkout Step Setup
The job definition and the use ofactions/checkout@v4are correctly implemented, ensuring that the repository is properly checked out for the build process.
22-28: DockerHub Login Step Review
Logging into DockerHub usingdocker/login-action@v3with credentials provided from secrets is implemented appropriately.
29-37: Jottacloud Repository Setup
The step that adds the Jottacloud repository is clear. Usingset -eensures that any command failure will abort the step, which is good for reliability.
38-47: Fetching the Latest jotta-cli Version
The script correctly retrieves the latest version ofjotta-cliusingapt-cache madisonand handles errors when the version is not found.
62-72: Version Comparison Logic
Comparing the currentjotta-cliversion with the latest Docker image version and setting theNO_UPDATEflag is implemented correctly. This flag is then used to conditionally execute subsequent steps.
73-77: Conditional QEMU Setup
The QEMU setup step is correctly conditioned on theNO_UPDATEflag, ensuring it runs only when a build is necessary.
78-82: Docker Buildx Setup
The conditional configuration for Docker Buildx is properly set, ensuring advanced multi-platform builds are only executed when needed.
83-89: Setting Date Variable for Image Tagging
Using the current date (formatted as yyyyMMdd) to create a version-date composite tag demonstrates good practice for versioning and traceability.
90-98: Docker Image Build and Push Configuration
The build step constructs image tags both aslatestand with a detailed version tag and then pushes them to Docker Hub. This dual-tag approach is beneficial for tagging consistency and rollback scenarios.
100-108: Git Repository Tagging and Pushing
Tagging the repository with the new image version and pushing the tag helps maintain version control and provides an audit trail. The use of the GitHub actor details in the configuration is appropriate.
this makes the condition more self explanatory, and make more sense when reading the code
There was a problem hiding this comment.
Pull Request Overview
This PR adds automated Docker image publishing and README synchronization for a jotta-cli Docker container. It introduces GitHub Actions workflows to automatically detect new jotta-cli versions, build multi-platform Docker images, and keep DockerHub documentation up-to-date.
- Automated Docker image building triggered weekly or when new jotta-cli versions are detected
- Multi-platform Docker image support (linux/amd64, linux/arm64/v8) with version-based tagging
- Automatic DockerHub README synchronization when the repository README.md changes
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| .github/workflows/publish-image.yaml | Main workflow for detecting jotta-cli version changes, building and publishing Docker images with multi-platform support |
| .github/workflows/update-dockerhub-readme.yaml | Workflow to automatically update DockerHub repository description from README.md changes |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: Get latest published Docker image version | ||
| run: | | ||
| DOCKER_VERSION=$(curl -s "https://registry.hub.docker.com/v2/repositories/${{ env.DOCKER_REPO }}/tags" | \ | ||
| jq -r '.results[].name' | grep -v '^latest$' | awk -F '-' '{print $1}' | sort -V | tail -n1) |
There was a problem hiding this comment.
The pipeline parsing logic assumes tag format with '-' delimiter but doesn't handle cases where tags might not contain '-'. This could cause awk -F '-' '{print $1}' to fail or return unexpected results for tags without dashes.
| jq -r '.results[].name' | grep -v '^latest$' | awk -F '-' '{print $1}' | sort -V | tail -n1) | |
| jq -r '.results[].name' | grep -v '^latest$' | grep -E '^[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -n1) |
| DOCKER_VERSION=$(curl -s "https://registry.hub.docker.com/v2/repositories/${{ env.DOCKER_REPO }}/tags" | \ | ||
| jq -r '.results[].name' | grep -v '^latest$' | awk -F '-' '{print $1}' | sort -V | tail -n1) | ||
| if [ -z "$DOCKER_VERSION" ]; then | ||
| echo "Error: Failed to retrieve latest Docker image version. Exiting." | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
The API call doesn't handle pagination. Docker Hub's API returns paginated results, so if there are many tags, the latest version might not be in the first page of results, causing the workflow to miss newer versions.
1 participant
Here's a GitHub action that auto-publishes updates to the README from GitHub to DockerHub. The main action checks if there's a new jotta-cli version compared to the one that's already published to DockerHub. This is done by comparing the string of the DockerHub image tag to the most recent jotta-cli version number.
This requires the
DOCKERHUB_USERNAME, andDOCKERHUB_TOKENrepository secrets to be added to the GitHub repo. The username is just the username used for logging into dockerhub, and the token is a personal login token that can be created in the account settings.Optionally the secret called
DOCKER_REPOcould also be added if the docker repo- or username doesn't match the GitHub repo- and username. This should then be in the formatUSERNAME/REPO_NAME.Solves #18
Important
Adds GitHub Actions to auto-update Docker images and DockerHub README based on
jotta-cliversion andREADME.mdchanges.publish-image.yamlto build and push Docker images weekly and on demand.update-dockerhub-readme.yamlto update DockerHub README onREADME.mdchanges.jotta-cliversion with DockerHub image tag inpublish-image.yaml.peter-evans/dockerhub-description@v3to update README on DockerHub.DOCKERHUB_USERNAMEandDOCKERHUB_TOKENfor authentication.DOCKER_REPOsecret for custom Docker repository names.This description was created by
for 1f5fd33. It will automatically update as commits are pushed.
Summary by CodeRabbit
README.mdfile, keeping published image information current.