City chatbot CI must lint, then unit-test, then package—never package before tests finish. How should the pipeline express that?
Select an answer to reveal the explanation.
Short Explanation
You can keep the chatbot pipeline reliable by using dependencies to make packaging wait until lint and unit tests succeed. Packaging in parallel, skipping the checks, or leaving the order undefined can let an unverified chatbot get packaged.
Full Explanation
Workflow dependencies make later jobs wait for earlier jobs to succeed, so packaging cannot outrun quality gates. For city chatbot CI that must lint, then unit-test, then package, declare dependencies so packaging waits until both lint and unit-test jobs succeed. A packaged chatbot artifact is trustworthy only after static checks and unit tests pass; explicit dependencies prevent packaging from proceeding before those results are known. Starting packaging immediately in parallel with lint regardless of test results fails because it breaks the intended quality sequence: failed unit tests should prevent a package from being treated as releasable, and packaging may waste effort on a commit that fails checks. Running packaging only while skipping lint and unit tests saves minutes at the cost of shipping unverified citizen-facing bot behavior. Leaving job order undefined fails because the orchestrator may run stages in a nondeterministic order, making the pipeline unreproducible and allowing packaging before tests finish. Exam caveat: dependencies must require upstream success, not merely job start; avoid soft dependencies that continue after an upstream failure unless that behavior is explicitly intended. Practical check: temporarily remove the package job’s dependency and verify it can run too early, then restore the dependency, deliberately fail unit tests, and confirm packaging does not produce a promoted artifact.