[feature] Support a deploy task type

[rhuanbarreto]

Is your feature request related to a problem? Please describe.

moon check runs all test and build type tasks. Very useful for local development and CI. But in CD, after we merge to main, I need to add one naming convention in tasks to be called deploy with the following config:

# .moon/tasks/backend.yml
tasks:
  deploy:
    command: docker build && docker push
    platform: system
    type: run
    local: true
    deps:
      - infra-login
      - build-backend
    options:
      persistent: false
      cache: false

Then in the CD pipeline I run moon run :deploy in order to deploy the whole monorepo.

Describe the solution you'd like

It would be good to have one new task type called deploy which assume some defaults. This would simplify a lot for the ones configuring the monorepo. Also a command moon deploy like moon check would be very useful and would make the mental model of using moon very homogeneous, once you could also use the moon deploy command to run a deploy to a development environment locally in addition to CD.

So the same task would be:

# .moon/tasks/backend.yml
tasks:
  deploy:
    command: docker build && docker push
    platform: system
    type: deploy
    deps:
      - infra-login
      - build-backend

And I could run all deploy tasks with moon deploy

Describe alternatives you've considered

Today only alternative is to run moon run :deploy or using filters or relying on naming conventions.

[milesj]

This could maybe be a preset: deploy that sets all the default/necessary options?

[rhuanbarreto]

A preset is good but this also needs to have its own command to help triggering it on CD for example.

[milesj]

moon deploy would basically be the same code as moon run though. I don't really see how they would be different.

[rhuanbarreto]

what could be a filter to target those kind of tasks without having a name convention like moon run :deploy?

[dudicoco]

@rhuanbarreto you could add a tag to the deploy tasks:

tags:
- deploy

However, I wouldn't recommend the flow that you are going for, I recommend building, testing and deploying both before and after merging to main.
Before merging to main you can deploy to a dev/staging/local environment.

In any case this should probably be moved to a discussion rather than an issue.

[rhuanbarreto]

I only do moon run :deploy on CD. On CI I still use moon ci to build/test/deploy on the dev environment. Although deploying for a PR and deploying for main there are 2 separate tasks.

Also, there's no possibility today to tag tasks. Only projects.

I still stand on keeping as a feature request. Your suggestions don't actually help the developer to simplify the mental model. My proposal simplifies how the process works for the developer:

Phase	Command
Development	moon run
Local Test/Build	moon check
CI Check/Deploy to development environment	moon ci
CD Deployment to dev/test/prod environment	moon deploy (proposed)

moon could even check for the CI=true env to guarantee the command is not being run locally and provide an override in case of an infra engineer wants to run this locally for debugging.

[milesj]

Right now, moon run/check/ci have a lot of overlap, but with different implementations. I do want to standardize them all on the same implementation. Deploy can probably be placed in there at that point.

[rhuanbarreto]

You are right @milesj, all those commands should be like an alias to moon run at the end by adding implicit filters. So in pseudocode those commands could be:

Alias	Command
moon check	moon run --filter "type=test or type=build" --all
moon ci	moon run --filter "options.runInCI=true" --all
moon deploy	moon run --filter "type=deploy" --all