CI: Add VERSION label to docker images #117
Conversation
WalkthroughThe recent updates involve enhancements to Docker image management across three GitHub workflow files. A new flag has been introduced to the Changes
Poem
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![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
Review Status
Configuration used: CodeRabbit UI
Files selected for processing (3)
- .github/workflows/docker-alpha.yml (1 hunks)
- .github/workflows/docker-beta.yml (1 hunks)
- .github/workflows/release-docker.yml (1 hunks)
Additional comments not posted (3)
.github/workflows/docker-beta.yml (1)
24-24: The addition of the--label=VERSION=${DOCKER_TAG}flag to the Docker build command is a good practice for version tracking. Ensure that theDOCKER_TAGenvironment variable is correctly set and used throughout the CI process.Verification successful
The review comment is verified as accurate. The
DOCKER_TAGenvironment variable is correctly set using a timestamp before its usage in the Docker build command, ensuring proper version tracking and consistency throughout the CI process. This setup aligns with best practices for dynamic and unique artifact tagging in CI/CD workflows.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify DOCKER_TAG is set before this step grep -B3 'docker build' .github/workflows/docker-beta.yml | grep 'DOCKER_TAG'Length of output: 201
Script:
#!/bin/bash # Search for any explicit setting of DOCKER_TAG in the workflow file grep 'DOCKER_TAG' .github/workflows/docker-beta.yml # Search for steps that might dynamically set DOCKER_TAG grep -A5 'run:' .github/workflows/docker-beta.yml | grep 'DOCKER_TAG'Length of output: 761
.github/workflows/docker-alpha.yml (1)
24-24: The addition of the--label=VERSION=${DOCKER_TAG}flag to the Docker build command is a good practice for version tracking. Ensure that theDOCKER_TAGenvironment variable is correctly set and used throughout the CI process.Verification successful
The
DOCKER_TAGenvironment variable is correctly set using a timestamp before its usage in the Docker build command, as shown in the.github/workflows/docker-alpha.ymlworkflow. This ensures unique versioning for each build and confirms the appropriate setting and usage ofDOCKER_TAGthroughout the CI process. The initial review comment is thus verified.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify DOCKER_TAG is set before this step grep -B3 'docker build' .github/workflows/docker-alpha.yml | grep 'DOCKER_TAG'Length of output: 202
Script:
#!/bin/bash # Search for any occurrences of DOCKER_TAG in the docker-alpha.yml workflow to understand its definition and usage grep 'DOCKER_TAG' .github/workflows/docker-alpha.yml -A2 -B2Length of output: 706
.github/workflows/release-docker.yml (1)
23-23: The addition of the--label=VERSION=${DOCKER_TAG}flag to the Docker build command is a good practice for version tracking, especially for release builds. Ensure that theDOCKER_TAGenvironment variable, derived from the GitHub release tag, is correctly used throughout the CI process.Verification successful
The verification process confirms that the
DOCKER_TAGenvironment variable is correctly set using the GitHub release tag (${{ github.event.release.tag_name }}) before its usage in the Docker build command. This aligns with best practices for version tracking in Docker images and confirms the accuracy of the initial review comment.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify DOCKER_TAG is set from the GitHub release tag before this step grep -B3 'docker build' .github/workflows/release-docker.yml | grep 'DOCKER_TAG'Length of output: 204
Script:
#!/bin/bash # Search for the setting of DOCKER_TAG in the entire workflow file grep 'DOCKER_TAG' .github/workflows/release-docker.ymlLength of output: 402
|
Hmm, this PR looks good in theory, but looks like the CI/CD is failing here, I'll take a look |
|
Looks like you might need to be a 'collaborator'. I've sent you an invite, once you've accepted that try re-running the docker alpha release here and let's see if it works |
|
for reference, the error being unable to login to docker.io: |
There was a problem hiding this comment.
Actionable comments posted: 0
Review Status
Configuration used: CodeRabbit UI
Files selected for processing (3)
- .github/workflows/docker-alpha.yml (1 hunks)
- .github/workflows/docker-beta.yml (1 hunks)
- .github/workflows/release-docker.yml (1 hunks)
Files skipped from review as they are similar to previous changes (3)
- .github/workflows/docker-alpha.yml
- .github/workflows/docker-beta.yml
- .github/workflows/release-docker.yml
|
Ah after some more digging, looks like it's because you're pushing from your repository to this one. The Github Actions Secrets page has this:
I think this is reasonable, I certainly don't want my docker token to be used everywhere! I can merge this PR for now, but if you need github actions to trigger in the future then it'd be better to use the nylonee/watchlistarr repository, or set up your own |
No description provided.