-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI: move SDM image publish to dedicated step #83
CI: move SDM image publish to dedicated step #83
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThis pull request introduces a new GitHub Actions workflow file, Changes
Possibly related issues
Possibly related PRs
Suggested labels
Suggested reviewers
Warning Rate limit exceeded@aaronsteers has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 24 minutes and 54 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
.github/workflows/publish_sdm_connector.yml (3)
24-39
: Consider adding pip caching for better performance.The build job looks good! Would you consider adding pip caching to speed up the builds? wdyt?
build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 + - uses: actions/setup-python@v4 + with: + python-version: '3.x' + + - uses: actions/cache@v3 + with: + path: ~/.cache/pip + key: ${{ runner.os }}-pip-${{ hashFiles('**/setup.py') }} + restore-keys: | + ${{ runner.os }}-pip- - uses: hynek/build-and-inspect-python-package@v2
98-164
: Consider enabling Docker layer caching.The Docker build steps look good! To speed up builds, would you consider enabling Docker layer caching? wdyt?
- name: Build and push (version tag) if: env.VERSION != '' && github.event.inputs.dry_run == 'false' uses: docker/build-push-action@v5 with: context: . platforms: linux/amd64,linux/arm64 push: true + cache-from: type=gha + cache-to: type=gha,mode=max tags: | airbyte/source-declarative-manifest:${{ env.VERSION }}
1-164
: Consider adding container vulnerability scanning.Since this is a dedicated workflow for publishing Docker images, would you consider adding a vulnerability scanning step using tools like Trivy or Snyk? This would help catch any security issues before publishing. wdyt?
Example implementation:
- name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@master with: image-ref: 'airbyte/source-declarative-manifest:${{ env.VERSION }}' format: 'table' exit-code: '1' ignore-unfixed: true vuln-type: 'os,library' severity: 'CRITICAL,HIGH'🧰 Tools
🪛 actionlint (1.7.3)
56-56: shellcheck reported issue in this script: SC2086:info:6:39: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC1073:error:12:1: Couldn't parse this if expression. Fix to allow more checks
(shellcheck)
66-66: shellcheck reported issue in this script: SC1050:error:12:31: Expected 'then'
(shellcheck)
66-66: shellcheck reported issue in this script: SC1072:error:12:31: Expected 'then'. Fix any mentioned problems and try again
(shellcheck)
66-66: shellcheck reported issue in this script: SC1140:error:12:31: Unexpected parameters after condition. Missing &&/||, or bad expression?
(shellcheck)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
.github/workflows/publish_sdm_connector.yml
(1 hunks).github/workflows/pypi_publish.yml
(0 hunks)
💤 Files with no reviewable changes (1)
- .github/workflows/pypi_publish.yml
🧰 Additional context used
🪛 actionlint (1.7.3)
.github/workflows/publish_sdm_connector.yml
56-56: shellcheck reported issue in this script: SC2086:info:6:39: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC1073:error:12:1: Couldn't parse this if expression. Fix to allow more checks
(shellcheck)
66-66: shellcheck reported issue in this script: SC1050:error:12:31: Expected 'then'
(shellcheck)
66-66: shellcheck reported issue in this script: SC1072:error:12:31: Expected 'then'. Fix any mentioned problems and try again
(shellcheck)
66-66: shellcheck reported issue in this script: SC1140:error:12:31: Unexpected parameters after condition. Missing &&/||, or bad expression?
(shellcheck)
🔇 Additional comments (2)
.github/workflows/publish_sdm_connector.yml (2)
1-22
: LGTM! Well-structured workflow configuration.
The workflow metadata and input parameters are well documented with clear descriptions. The optional version input with fallback logic and dry run capability provide good flexibility.
40-53
: LGTM! Well-configured publish job setup.
The publish job is properly configured with build dependency and environment settings.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (5)
.github/workflows/publish_sdm_connector.yml (5)
9-16
: Consider adding pattern validation for version input?The version input could benefit from a pattern validation to ensure it matches semantic versioning format. wdyt about adding something like this?
version: description: The version to publish, ie 1.0.0 or 1.0.0-dev1. If omitted, and if run from a release branch, the version will be inferred from the git tag. If omitted, and if run from a non-release branch, then only a SHA-based Docker tag will be created. required: false + pattern: '^[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9]+)?$'
24-39
: Add caching to speed up builds?The build job could be faster with dependency caching. How about adding the Python cache action? Something like:
build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 + - uses: actions/setup-python@v4 + with: + python-version: '3.x' + - uses: actions/cache@v3 + with: + path: ~/.cache/pip + key: ${{ runner.os }}-pip-${{ hashFiles('**/setup.py') }} + restore-keys: | + ${{ runner.os }}-pip-
92-96
: Consider more comprehensive prerelease detection?The current regex only considers exact semver (X.Y.Z) as non-prerelease. Should we also handle common prerelease indicators? Something like:
- if [[ "${VERSION}" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then + if [[ "${VERSION}" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]] && ! [[ "${VERSION}" =~ (rc|alpha|beta|dev) ]]; then
116-130
: Consider using jq for more robust tag checking?The current tag checking might fail with rate limits. How about using the Docker Hub API with jq? Something like:
- name: Check for existing tag if: env.VERSION != '' run: | tag="airbyte/source-declarative-manifest:${{ env.VERSION }}" - if [ -z "$tag" ]; then - echo "Error: VERSION is not set. Ensure the tag follows the format 'refs/tags/vX.Y.Z'." - exit 1 - fi echo "Checking if tag '$tag' exists on DockerHub..." - if DOCKER_CLI_EXPERIMENTAL=enabled docker manifest inspect "$tag" > /dev/null 2>&1; then + if curl -s "https://hub.docker.com/v2/repositories/airbyte/source-declarative-manifest/tags/${VERSION}" | jq -e '.name' > /dev/null; then echo "The tag '$tag' already exists on DockerHub. Skipping publish to prevent overwrite." exit 1 fi
131-163
: Consider consolidating build steps?We have three very similar build steps that only differ in tags. Would it be cleaner to consolidate them? Something like:
- - name: Build and push (sha tag) - if: env.VERSION == '' && github.event.inputs.dry_run == 'false' - uses: docker/build-push-action@v5 - with: - context: . - platforms: linux/amd64,linux/arm64 - push: true - tags: | - airbyte/source-declarative-manifest:${{ github.sha }} - - - name: Build and push (version tag) - if: env.VERSION != '' && github.event.inputs.dry_run == 'false' - uses: docker/build-push-action@v5 - with: - context: . - platforms: linux/amd64,linux/arm64 - push: true - tags: | - airbyte/source-declarative-manifest:${{ env.VERSION }} - - - name: Build and push ('latest' tag) - if: env.VERSION != '' && env.IS_PRERELEASE == 'false' && github.event.inputs.dry_run == 'false' - uses: docker/build-push-action@v5 - with: - context: . - platforms: linux/amd64,linux/arm64 - push: true - tags: | - airbyte/source-declarative-manifest:latest + - name: Prepare tags + id: prep + run: | + TAGS="airbyte/source-declarative-manifest:${{ github.sha }}" + if [ -n "$VERSION" ]; then + TAGS="$TAGS,airbyte/source-declarative-manifest:${{ env.VERSION }}" + if [ "$IS_PRERELEASE" = "false" ]; then + TAGS="$TAGS,airbyte/source-declarative-manifest:latest" + fi + fi + echo "tags=${TAGS}" >> $GITHUB_OUTPUT + + - name: Build and push + if: github.event.inputs.dry_run == 'false' + uses: docker/build-push-action@v5 + with: + context: . + platforms: linux/amd64,linux/arm64 + push: true + tags: ${{ steps.prep.outputs.tags }}This would make the workflow more maintainable and reduce duplication. wdyt?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/publish_sdm_connector.yml
(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.3)
.github/workflows/publish_sdm_connector.yml
56-56: shellcheck reported issue in this script: SC2086:info:6:48: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC2086:info:6:24: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC2086:info:24:30: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC2086:info:27:33: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC2086:info:29:32: Double quote to prevent globbing and word splitting
(shellcheck)
🔇 Additional comments (2)
.github/workflows/publish_sdm_connector.yml (2)
40-53
: LGTM! Clean job setup with proper conditions and environment.
97-103
: LGTM! Proper artifact handling between jobs.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
.github/workflows/publish_sdm_connector.yml (4)
9-16
: How about adding more specific version format requirements to the description? wdyt?The description could be more explicit about the expected version format. Maybe something like:
description: | - The version to publish, ie 1.0.0 or 1.0.0-dev1. + The version to publish (e.g., '1.0.0' for releases or '1.0.0-dev1' for prereleases). + Must follow semantic versioning format: MAJOR.MINOR.PATCH[-PRERELEASE]. If omitted, and if run from a release branch, the version will be inferred from the git tag. If omitted, and if run from a non-release branch, then only a SHA-based Docker tag will be created.
45-47
: Consider using a reusable environment URL? wdyt?Instead of hardcoding the DockerHub URL, we could make it more maintainable by using a repository variable. Something like:
environment: name: DockerHub - url: https://hub.docker.com/r/airbyte/source-declarative-manifest/tags + url: ${{ vars.DOCKER_HUB_TAGS_URL }}
116-130
: Consider enhancing the tag check with rate limiting protection? wdyt?The DockerHub API has rate limits. Maybe we could add some retry logic:
run: | tag="airbyte/source-declarative-manifest:${{ env.VERSION }}" if [ -z "$tag" ]; then echo "Error: VERSION is not set. Ensure the tag follows the format 'refs/tags/vX.Y.Z'." exit 1 fi echo "Checking if tag '$tag' exists on DockerHub..." + max_attempts=3 + attempt=1 + while [ $attempt -le $max_attempts ]; do + echo "Attempt $attempt of $max_attempts" if DOCKER_CLI_EXPERIMENTAL=enabled docker manifest inspect "$tag" > /dev/null 2>&1; then echo "The tag '$tag' already exists on DockerHub. Skipping publish to prevent overwrite." exit 1 + elif [ $? -eq 1 ]; then + echo "No existing tag '$tag' found. Proceeding with publish." + exit 0 + else + echo "Rate limit or network error. Waiting before retry..." + sleep $((attempt * 5)) + attempt=$((attempt + 1)) + fi + done - echo "No existing tag '$tag' found. Proceeding with publish." + echo "Error: Failed to check tag after $max_attempts attempts" + exit 1
131-163
: How about adding Docker layer caching to speed up builds? wdyt?The build steps could benefit from caching. Consider adding these options:
with: context: . platforms: linux/amd64,linux/arm64 push: true + cache-from: type=gha + cache-to: type=gha,mode=max tags: | airbyte/source-declarative-manifest:${{ env.VERSION }}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/publish_sdm_connector.yml
(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.3)
.github/workflows/publish_sdm_connector.yml
56-56: shellcheck reported issue in this script: SC2086:info:6:48: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC2086:info:6:24: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC2086:info:24:30: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC2086:info:27:33: Double quote to prevent globbing and word splitting
(shellcheck)
66-66: shellcheck reported issue in this script: SC2086:info:29:32: Double quote to prevent globbing and word splitting
(shellcheck)
🔇 Additional comments (2)
.github/workflows/publish_sdm_connector.yml (2)
24-39
: LGTM! Clean and efficient build setup.
The build job uses the latest action versions and properly handles artifact paths.
98-102
: LGTM! Proper artifact handling.
The artifact download step is well-configured and uses the latest action version.
Findings:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Will follow up with the update to the Dockerfile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
.github/workflows/publish_sdm_connector.yml (2)
9-16
: How about adding version format validation to the input? wdyt?The version input description is clear, but we could add a pattern to validate the format upfront. This would catch invalid versions earlier in the process.
version: description: The version to publish, ie 1.0.0 or 1.0.0-dev1. If omitted, and if run from a release branch, the version will be inferred from the git tag. If omitted, and if run from a non-release branch, then only a SHA-based Docker tag will be created. required: false + pattern: '^v?\d+\.\d+\.\d+(-[a-zA-Z0-9]+)?$'
143-164
: How about optimizing the Docker builds? wdyt?We could improve build performance by:
- Adding build caching
- Making platforms configurable
- name: Build and push (sha tag) if: env.VERSION == '' && github.event.inputs.dry_run == 'false' uses: docker/build-push-action@v5 with: context: . - platforms: linux/amd64,linux/arm64 + platforms: ${{ inputs.platforms || 'linux/amd64,linux/arm64' }} push: true + cache-from: type=gha + cache-to: type=gha,mode=max tags: | airbyte/source-declarative-manifest:${{ github.sha }}Would you like me to add a new workflow input for configuring build platforms?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/publish_sdm_connector.yml
(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.3)
.github/workflows/publish_sdm_connector.yml
30-30: shellcheck reported issue in this script: SC2086:info:6:48: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:6:24: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:24:30: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:25:30: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:28:33: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:29:33: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:31:32: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:32:32: Double quote to prevent globbing and word splitting
(shellcheck)
101-101: property "version" is not defined in object type {}
(expression)
102-102: property "is_prerelease" is not defined in object type {}
(expression)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
.github/workflows/publish_sdm_connector.yml (2)
9-16
: How about enhancing the version input description? wdyt?The description could be more explicit about version format requirements. Consider:
version: description: - The version to publish, ie 1.0.0 or 1.0.0-dev1. + The version to publish (e.g., '1.0.0' or '1.0.0-dev1'). + Must follow semantic versioning format (X.Y.Z[-suffix]). If omitted, and if run from a release branch, the version will be inferred from the git tag. If omitted, and if run from a non-release branch, then only a SHA-based Docker tag will be created.
147-154
: How about adding Docker layer caching to speed up builds? wdyt?The build steps could benefit from Docker layer caching to improve build times. Consider:
uses: docker/build-push-action@v5 with: context: . platforms: linux/amd64,linux/arm64 push: true + cache-from: type=gha + cache-to: type=gha,mode=max tags: |Also applies to: 158-165, 170-176
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/publish_sdm_connector.yml
(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.3)
.github/workflows/publish_sdm_connector.yml
30-30: shellcheck reported issue in this script: SC2086:info:6:48: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:6:24: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:24:30: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:25:30: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:28:33: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:29:33: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:31:32: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:32:32: Double quote to prevent globbing and word splitting
(shellcheck)
102-102: property "version" is not defined in object type {}
(expression)
103-103: property "is_prerelease" is not defined in object type {}
(expression)
🔇 Additional comments (2)
.github/workflows/publish_sdm_connector.yml (2)
1-176
: LGTM! The workflow is well-structured and robust.
The workflow effectively handles:
- Version validation and management
- Multi-platform builds
- Prerelease version detection
- Existing tag checks
🧰 Tools
🪛 actionlint (1.7.3)
30-30: shellcheck reported issue in this script: SC2086:info:6:48: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:6:24: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:24:30: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:25:30: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:28:33: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:29:33: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:31:32: Double quote to prevent globbing and word splitting
(shellcheck)
40-40: shellcheck reported issue in this script: SC2086:info:32:32: Double quote to prevent globbing and word splitting
(shellcheck)
102-102: property "version" is not defined in object type {}
(expression)
103-103: property "is_prerelease" is not defined in object type {}
(expression)
98-100
: Should we verify the DockerHub environment configuration? wdyt?
Please ensure that the DockerHub
environment is properly configured in GitHub with the required secrets and any necessary approval processes or protection rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
.github/workflows/publish_sdm_connector.yml (4)
9-16
: How about enhancing the version input description? wdyt?The description could be more explicit about the expected version format. Consider:
version: description: - The version to publish, ie 1.0.0 or 1.0.0-dev1. + The version to publish (e.g., '1.0.0' or '1.0.0-dev1'). + Must follow semantic versioning format: X.Y.Z[-suffix]. If omitted, and if run from a release branch, the version will be inferred from the git tag. If omitted, and if run from a non-release branch, then only a SHA-based Docker tag will be created.
68-74
: Should we make the prerelease version detection more robust? wdyt?The current regex only matches exact semver without prerelease tags. Consider adding validation for the prerelease suffix format:
- if [[ "${VERSION}" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then + if [[ "${VERSION}" =~ ^[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?$ ]]; then echo "IS_PRERELEASE=false" >> $GITHUB_ENV echo "IS_PRERELEASE=false" >> $GITHUB_OUTPUT else echo "IS_PRERELEASE=true" >> $GITHUB_ENV echo "IS_PRERELEASE=true" >> $GITHUB_OUTPUT fiThis would ensure that prerelease suffixes follow the semver spec (e.g.,
-alpha.1
,-beta.2
,-rc.1
).
153-154
: Should we optimize the Docker build context? wdyt?The build context includes the entire repository, which might slow down builds. Consider:
- Adding
.dockerignore
to exclude unnecessary files- Using a specific subdirectory as context if possible
Example
.dockerignore
:.git/ .github/ tests/ *.md *.pyc __pycache__/
Also applies to: 164-165, 176-177
128-132
: Should we consider using short-lived Docker Hub tokens? wdyt?For enhanced security, consider:
- Using short-lived access tokens instead of a password
- Setting token expiration to match your release cycle
- Adding token scope restrictions to only allow push access
This helps minimize the impact if credentials are ever compromised.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/publish_sdm_connector.yml
(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.3)
.github/workflows/publish_sdm_connector.yml
30-30: shellcheck reported issue in this script: SC2086:info:6:48: Double quote to prevent globbing and word splitting
(shellcheck)
41-41: shellcheck reported issue in this script: SC2086:info:6:24: Double quote to prevent globbing and word splitting
(shellcheck)
41-41: shellcheck reported issue in this script: SC2086:info:24:30: Double quote to prevent globbing and word splitting
(shellcheck)
41-41: shellcheck reported issue in this script: SC2086:info:25:30: Double quote to prevent globbing and word splitting
(shellcheck)
41-41: shellcheck reported issue in this script: SC2086:info:28:33: Double quote to prevent globbing and word splitting
(shellcheck)
41-41: shellcheck reported issue in this script: SC2086:info:29:33: Double quote to prevent globbing and word splitting
(shellcheck)
41-41: shellcheck reported issue in this script: SC2086:info:31:32: Double quote to prevent globbing and word splitting
(shellcheck)
41-41: shellcheck reported issue in this script: SC2086:info:32:32: Double quote to prevent globbing and word splitting
(shellcheck)
The blast radius for SDM deploys is too large for us to constantly deploy. This moves the process to a single-step process that we can trigger.
How publishing would work with the workflow trigger:
TODO:
airbyte-platform-internal
repo) when this flow with run on a non-prelease version.Normal Releases
The preferred way to run this (for production releases) would be to select an already-deployed release tag as in this screenshot:
In that case, you only have to select the release tag and run the workflow from there.
To add:
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Bug Fixes
Chores