ci: ensure image is published once #1746
Conversation
📝 WalkthroughWalkthroughThis pull request introduces significant changes to the GitHub Actions workflows, primarily focusing on restructuring the release and deployment processes. The main modifications include removing the Changes
Possibly related PRs
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (2)
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
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/ci-cd-release-please.yml (1)
27-33: Consider caching the previous release SHA.The workflow fetches the previous release SHA on every run. Consider caching this value to reduce API calls.
- name: Get previous release SHA id: get-previous-release + env: + GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} + CACHE_KEY: previous-release-sha run: | - sha=$(gh api repos/${{ github.repository }}/releases/latest --jq '.target_commitish') - echo "sha=${sha}" >> $GITHUB_OUTPUT - env: - GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} + if ! sha=$(gh variable list --json name,value | jq -r '.[] | select(.name=="'$CACHE_KEY'") | .value'); then + sha=$(gh api repos/${{ github.repository }}/releases/latest --jq '.target_commitish') + gh variable set "$CACHE_KEY" --body "$sha" + fi + echo "sha=${sha}" >> $GITHUB_OUTPUT
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.github/workflows/ci-cd-main.yml(0 hunks).github/workflows/ci-cd-release-please.yml(1 hunks).github/workflows/ci-cd-staging.yml(3 hunks).github/workflows/ci-cd-yt01.yml(3 hunks).github/workflows/workflow-send-ci-cd-status-slack-message.yml(3 hunks)
💤 Files with no reviewable changes (1)
- .github/workflows/ci-cd-main.yml
🔇 Additional comments (7)
.github/workflows/ci-cd-release-please.yml (3)
13-16: LGTM! Required permissions are correctly configured.The workflow has the necessary permissions for release management:
contents: writefor creating releasespull-requests: writefor release PRspackages: writefor publishing Docker images
71-84: LGTM! Comprehensive failure notification setup.The Slack notification job:
- Runs on any failure (
always() && failure())- Includes status of all critical jobs
- Uses appropriate secrets for Slack integration
35-39: Verify the release-please token permissions.The workflow uses a custom PAT (
RELEASE_PLEASE_PAT) instead of the defaultGITHUB_TOKEN. Ensure this token has the minimum required permissions.✅ Verification successful
Custom PAT with minimum required permissions is a security best practice ✅
The use of
RELEASE_PLEASE_PATwith specific scopes is actually recommended over using the defaultGITHUB_TOKEN. The token only needs these permissions:
contents:write- for releases and commitspull_requests:write- for release PRsrepository_dispatch:write- for deployment triggers🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if the RELEASE_PLEASE_PAT token has excessive permissions # Test: List repository variables to check token permissions gh api \ -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2022-11-28" \ /repos/$GITHUB_REPOSITORY/actions/variablesLength of output: 227
Script:
#!/bin/bash # Search for documentation and configuration related to release-please permissions echo "=== Searching for documentation files ===" fd -e md -e txt | xargs rg -i "release.?please|token|permission" || true echo -e "\n=== Searching workflow files for release-please configurations ===" fd "^.*\.ya?ml$" .github/workflows/ | xargs rg -i "release.?please" -C 3 || true echo -e "\n=== Searching for security-related comments ===" rg -i "PAT|token|permission|scope" .github/workflows/ || trueLength of output: 34053
.github/workflows/workflow-send-ci-cd-status-slack-message.yml (1)
37-44: LGTM! New status inputs are well-documented.The new inputs for tracking release statuses:
release_please_statusnotify_release_created_status
are properly defined with clear descriptions and default values..github/workflows/ci-cd-staging.yml (1)
5-6: LGTM! Deployment trigger changed to repository dispatch.The workflow now triggers on
release_createdevents instead of push, aligning with the new release-driven deployment strategy..github/workflows/ci-cd-yt01.yml (2)
5-6: LGTM! Deployment trigger matches staging workflow.The workflow consistently uses the same
release_createdtrigger as the staging workflow.
65-65: LGTM! Job dependencies properly updated.The removal of the publish job is properly reflected in the job dependencies:
deploy-appsnow depends on[get-current-version, check-for-changes, deploy-infra]send-slack-message-on-failurecorrectly includes all remaining jobsAlso applies to: 145-145
Description
This change streamlines our Docker image management by building and publishing images only once when a release is created, rather than rebuilding for each environment. These published images are then reused across staging, yt01 and production deployments.
Technical Changes
Next up:
Related Issue(s)
Verification
Documentation
docs-directory, Altinnpedia or a separate linked PR in altinn-studio-docs., if applicable)