When we're tagging a version that's not the latest version, then don't update the `latest` Docker image on Docker hub. Like, if the current latest is `v1.20`, and we publish the hotfix tag `v1.18.1` to fix a critical bug in `v1.18`, then we only want to publish the Docker image at the tag `v1.18.1`, and _not_ update `latest`. We want `latest` to continue to point to `v1.20`. Tested on a separate private repo, confirmed working. ## Communication Should the DevRel and Marketing teams inform users about this change? - [ ] Yes - [x] No <!-- This is an auto-generated comment: Cypress test results --> > [!WARNING] > Tests have not run on the HEAD 21b3f9fe1ec7beea8b1f72b20f5406fb14fca4aa yet > <hr>Sat, 21 Dec 2024 05:33:37 UTC <!-- end of auto-generated comment: Cypress test results --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Introduced a streamlined GitHub Actions workflow for Docker image tagging. - Added a summary log for workflow execution details. - Enhanced Docker tag generation with validation and error handling. - **Bug Fixes** - Improved validation for GitHub reference formats to prevent failures. - **Documentation** - Updated workflow names and outputs for clarity and ease of use. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|---|---|---|
| .. | ||
| docs | ||
| scripts | ||
| ad-hoc-docker-image.yml | ||
| build-chromatic.yml | ||
| build-client-server-count.yml | ||
| build-client-server.yml | ||
| build-docker-image.yml | ||
| build-storybook.yml | ||
| caddy-routes-test.yml | ||
| ci-client-cyclic-deps-check.yml | ||
| ci-test-custom-script.yml | ||
| ci-test-hosted.yml | ||
| ci-test-limited-with-count.yml | ||
| ci-test-limited.yml | ||
| cleanup-dp.yml | ||
| client-build.yml | ||
| client-lint.yml | ||
| client-prettier.yml | ||
| client-unit-tests.yml | ||
| close-labeler.yml | ||
| copy-labels.yml | ||
| docker-base-image.yml | ||
| duplicate-issue-detector.yml | ||
| github-release.yml | ||
| helm-release.yml | ||
| integration-tests-command.yml | ||
| issue-report-config.json | ||
| mastermind-labeler.yml | ||
| ok-to-test.yml | ||
| on-demand-build-docker-image-deploy-preview.yml | ||
| pr-automation.yml | ||
| pr-cypress.yml | ||
| pr-labeler.yml | ||
| quality-checks.yml | ||
| README.md | ||
| release-drafter.yml | ||
| rts-build.yml | ||
| server-build.yml | ||
| server-spotless.yml | ||
| stale.yml | ||
| sync-release-to-pg.yml | ||
| test-build-docker-image.yml | ||
| test-storybook.yml | ||
| test-vulnerabilities-data.yml | ||
The following list describes all the workflows that are configured to run in this repository:
Release process related Actions
- Build RTS Workflow
- Appsmith Client Build Workflow
- Appsmith External Integration Test Workflow
- Appsmith Github Release Workflow
- Ok To Test
- Appsmith Server Workflow
- Test, build and push Docker Image
Utility Actions
- Mark stale issues and pull requests
- Label PRs based on title
- Release Drafter
- Remove old artifacts
- Sync Community workflow
- Potential Duplicate Issues
- Mastermind Labeler Workflow
Build RTS Workflow
Workflow file: build-rts.yml Triggered on every commit to the rts folder. This workflow is responsible for building the RTS Node server. There are dummy steps for ui-tests and packaging. (Comment: Useless right now because it does not have ui-test-result)
Appsmith Client Build Workflow
Workflow file: client-build.yml Triggered on every commit to the client folder. This workflow is responsible for building & unit-testing the client side.
Appsmith Server Workflow
Workflow file: server.yml Triggered on every commit to the server folder. This workflow is responsible for building & unit-testing the Java server codebase.
Appsmith External Integration Test Workflow
Workflow file: external-client-test.yml Triggered only by the ok to test command dispatch. This workflow is responsible for building, unit-testing, integration testing and packaging both server and client code base. (Comment: Notably not RTS)
Appsmith Github Release Workflow
Workflow file: github-release.yml
Triggered on release event on Github. This workflow is responsible for building client, server and RTS binaries and packaging them to the latest as well as the relevant release tag on Docker.
Ok To Test
Workflow file: ok-to-test.yml Triggered by PR comments. This workflow triggers a repository dispatch for the Appsmith External Integration Test Workflow.
Test, build and push Docker Image
Workflow file: test-build-docker-image.yml Triggered by PR reviews and push to release or master. This workflow is responsible for building client, server and RTS binaries and packaging them to fata container as well as the older separate containers.
Mark stale issues and pull requests
Workflow file: stale.yml
Label PRs based on title
Workflow file: pr-labeler.yml
Release Drafter
Workflow file: release-drafter.yml
Remove old artifacts
Workflow file: remove-old-artifacts.yml
Sync Community workflow
Workflow file: sync-community-repo.yml
Potential Duplicate Issues
Workflow file: duplicate-issue-detector.yml
Mastermind Labeler Workflow
Workflow file: mastermind-labeler.yml