[EVO-1998] ci(docker): publish :develop image on merge to develop#21
Merged
gomessguii merged 2 commits intoJul 8, 2026
Merged
Conversation
The publish workflow only triggered on push to main and version tags, so merges to develop never rebuilt the evoapicloud/evo-ai-processor-community :develop image — staging (which runs :develop) silently ran stale code. - Add develop to the push branch trigger. - Add a develop case to the manifest tag resolver so it publishes :develop (and :develop-<sha> for traceability), mirroring main. - Add workflow_dispatch for manual rebuilds.
Reviewer's guide (collapsed on small PRs)Reviewer's GuideUpdates the Docker publish GitHub Actions workflow so that merges to the develop branch build and publish a :develop image (and a SHA-suffixed variant), add develop to push triggers, and allow manual rebuilds via workflow_dispatch, without altering existing build logic or credentials. Flow diagram for updated Docker publish workflow triggers and taggingflowchart TD
A[Push to main]
B[Push to develop]
C[Push tag v*.*.*]
D[workflow_dispatch]
A --> E[Workflow docker-publish.yml]
B --> E
C --> E
D --> E
E --> F{GH_REF}
F -->|refs/tags/v*.*.*| G[Set TAGS
IMAGE:VERSION
IMAGE:latest]
F -->|refs/heads/main| H[Set TAGS
IMAGE:latest
IMAGE:main-SHA_SHORT]
F -->|refs/heads/develop| I[Set TAGS
IMAGE:develop
IMAGE:develop-SHA_SHORT]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- In the tag resolution step, consider explicitly failing the job if no TAGS value is derived (e.g., with a final
elsethat exits non‑zero) so future workflow changes or additional branches don’t silently skip publishing without a clear error. - Since
developnow shares the same workflow, it might be worth extracting the branch→tag mapping into a small, clearly separated block or function (e.g., a case statement) to make future additions (other long‑lived branches or preview tags) easier to maintain and reason about.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In the tag resolution step, consider explicitly failing the job if no TAGS value is derived (e.g., with a final `else` that exits non‑zero) so future workflow changes or additional branches don’t silently skip publishing without a clear error.
- Since `develop` now shares the same workflow, it might be worth extracting the branch→tag mapping into a small, clearly separated block or function (e.g., a case statement) to make future additions (other long‑lived branches or preview tags) easier to maintain and reason about.
## Individual Comments
### Comment 1
<location path=".github/workflows/docker-publish.yml" line_range="5-9" />
<code_context>
on:
push:
- branches: [main]
+ branches: [main, develop]
tags: ["v*.*.*"]
pull_request:
branches: [main, develop]
+ workflow_dispatch:
permissions:
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider constraining manual workflow_dispatch runs to avoid unexpected branches
With `workflow_dispatch` enabled, this job can now be triggered from any ref, not just `main`/`develop`. Given the branch/tag‑specific tagging logic later in the file, a manual run from another branch could produce incorrect tags or an empty `TAGS`. If this workflow is only meant to run manually for `main`/`develop` (or specific tags), consider restricting/validating the ref via inputs or clearly documenting that only those branches should be used when triggering it manually.
Suggested implementation:
```
pull_request:
branches: [main, develop]
workflow_dispatch:
inputs:
ref_hint:
description: "Manual runs should only target main or develop branches (or release tags)"
required: false
default: "main"
```
To fully implement the validation part of the suggestion, you should also add a guard step near the start of the relevant job (e.g. your build/publish job) to fail manual runs on unsupported refs. For example (adjust job/step names to match your existing workflow):
```yaml
jobs:
build-and-publish:
runs-on: ubuntu-latest
steps:
- name: Validate manual trigger ref
if: ${{ github.event_name == 'workflow_dispatch' }}
run: |
echo "GITHUB_REF=${GITHUB_REF}"
if [[ "${GITHUB_REF}" != "refs/heads/main" && "${GITHUB_REF}" != "refs/heads/develop" && "${GITHUB_REF}" != refs/tags/v* ]]; then
echo "This workflow may only be run manually from main, develop, or v* tags."
exit 1
fi
# existing steps...
```
This ensures that even if someone manually selects another branch in the UI, the workflow will exit early and avoid generating incorrect or empty tags based on the later `GH_REF`-dependent tagging logic you already have in the file.
</issue_to_address>
### Comment 2
<location path=".github/workflows/docker-publish.yml" line_range="144-145" />
<code_context>
TAGS="${IMAGE}:${VERSION},${IMAGE}:latest"
elif [[ "${GH_REF}" == refs/heads/main ]]; then
TAGS="${IMAGE}:latest,${IMAGE}:main-${SHA_SHORT}"
+ elif [[ "${GH_REF}" == refs/heads/develop ]]; then
+ TAGS="${IMAGE}:develop,${IMAGE}:develop-${SHA_SHORT}"
fi
</code_context>
<issue_to_address>
**issue:** Handle TAGS for non-main/non-develop refs or fail early to avoid empty tags
With this change, `TAGS` is only set for tag refs, `main`, or `develop`. If this job runs on any other ref (e.g., `workflow_dispatch` on a feature branch), `TAGS` will be empty and downstream steps may mis-tag or publish incorrectly. Consider adding a default/else case (safe no-op/safe tag) or failing explicitly when `GH_REF` doesn’t match a supported pattern so these cases are handled deterministically.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
workflow_dispatch can now run from any ref; a run on an unsupported ref would leave TAGS empty and fail confusingly in the manifest step after building. Fail early in tag resolution with a clear message instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problema
O
docker-publish.ymldo processor dispara só empush → maine tagsv*.*.*. Merges emdevelopnunca rebuildam a imagemevoapicloud/evo-ai-processor-community:develop. Como o staging (evo_crm_test) roda:develop, ele silenciosamente rodava código velho — o:developestava congelado em 2026-05-25, faltando, entre outras coisas, o RBAC object-level/bot-key do épico EVO-2035 (PR #20).Os outros 3 serviços do épico (auth/CRM/frontend) buildam
:developnormal — o gap de trigger era só aqui.Correção
developadicionado ao trigger depush.developadicionado no resolvedor de tags do jobmerge, publicando:develop(e:develop-<sha>pra rastreabilidade), espelhando o comportamento demain.workflow_dispatchadicionado pra rebuild manual.Sem mudança nos jobs de build/PR nem nas credenciais.
Depois do merge
O push em
developvai buildar/publicar:develop; então é só atualizar o serviço no staging (docker service update --image evoapicloud/evo-ai-processor-community:develop ...) pra o processor entrar no código do épico.Refs: EVO-1998, EVO-2035.
Summary by Sourcery
Ensure the Docker image for the processor is built and published for the develop branch alongside main, including appropriate tagging and manual rebuild support.
Build:
CI: