text:
[feature] Provide an option to disable fail-fast behavior and process as much of the task graph as possible

Thanks for your great project.   I'd like to learn to rust, so if any of the issues I've submitted could be good beginner tasks, let me know. I was halfway to fixing the powershell bug when you submitted your PR 😄
Is your feature request related to a problem? Please describe.

Currently I use pre-commit to manage and run my git hooks, but I hate that it requires me to maintain a configuration file with a bunch of information that is redundant with settings owned by moon.  Moon is very close to being a complete replacement for pre-commit, which would give me a single source of truth and a more elegant solution, but it's missing a few features.
Here are the required features (check boxes indicate whether moon satisfies the requirement):

[x] Install necessary toolchains to run tasks
[x] Specify file patterns for when to trigger a task (solved with inputs)
[x] Operate on staged files (solved with --affected --status=staged)
[x] Pass modified input files to the task  (solved with affectedFiles)
[x] * Return non-zero on failure of any task
[x] * Ability to process all tasks even if one fails   (solved with allowFailure)
[ ] stash outstanding changes before running tasks, then restore the stash on completion

* Tasks with an asterisk are not fully satisfied by moon, because we can't get both of these features at the same time.  See below.
That's really close!
As far as I can tell, moon immediately aborts all queued and unqueued tasks as soon as a failure is encountered (so long as the failed task does not have allowFailure = true).  For certain cases, like linting, failing fast is not desirable.  I would like an option to continue processing every task that does not have a failure in its upstream dependents.
For example, consider a repo with two projects -- foo and bar -- with a set of global tasks like this:
tasks:
  will_fail:
    command: 'false'
    options:
      cache: false

  will_succeed:
    command: 'true'
    options:
      cache: false

  lint:
    deps: [will_fail, will_succeed]
    command: "echo 'lint complete'"

When running moon run :lint I would like all will_fail and will_succeed tasks to run.  This is safe because they are not dependent on each other. The foo:lint and foo:bar tasks would not run their commands because they have failures in their deps (foo:will_fail and bar:will_fail respectively), so they are not safe to run.
This behavior is particularly desirable for lint tasks, where a developer wants to perform or get feedback on a number of (usually unrelated) tasks as aggressively as possible.   I don't want all of my check_yaml tasks to abort just because one of my check_python tasks fail:  I want to know all the failures up front so that I can address all the issues together.
Instead, what currently happens is that tasks are aborted as soon as the first failure is detected, so I have to fix, rerun, and repeat to progressively expose issues, which is a waste of time.
Describe alternatives you've considered
The closest that I can get to the desired behavior is to set allowFailure = true for my lint tasks.
tasks:
  fails:
    command: 'false'
    options:
      cache: false
      allowFailure: true

  succeeds:
    command: 'true'
    options:
      cache: false
      allowFailure: true

There are two problems with this:

I can no longer group these tasks together under another task, because tasks with allowFailure = true are not allowed to be depended upon.   This means that users need to provide the full list of lint tasks when calling moon run, or I need to create a wrapper script to do this for them.
If a task with allowFailure = true fails, moon run will still exit 0.  Thus, when used as a precommit hook, it will not stop git commit from proceeding.  This makes it completely ineffective as a precommit solution.

Describe the solution you'd like
Option 1:  global control over fail-fast behavior
One solution is a global option to disable the default fail-fast behavior.  pre-commit provides control over this behavior with a global option called fail_fast.  It defaults to false.
Unlike the task-level allowFailure option, moon run should still return 1 if a task fails with failFast = false.
This global option could be a CLI flag for moon run or an option in .moon/workspace.yml.
Option 2:  Add a task-level option to control failure propagation
A finer-grained solution could be to add an option to control the scope of failure propagation.
Possible semantics:

abortTasksOnFailure = "all", "downstream", or "none". Defaults to "all".
failurePropagationScope = "global", "project", "downstream", "none".  Defaults to "global".

"none" is equivalent to  allowFailure=true.  Only "none" would cause moon run to exit 0 on task failure.
Setting this in taskOptions within .moon/tasks.yml would have the effect of globally disabling the fail-fast behavior:
taskOptions:
  abortTasksOnFailure:  downstream

If a task with abortTasksOnFailure = all fails it should not abort a task with abortTasksOnFailure = downstream.

Additional context

We actually support this "fail immediately, or fail at the end" functionality already, but it's internal only right now. It's how moon run (immediate) and moon ci (end) work, even though the share the same code.
I can bubble this functionality up to a CLI flag so it can be toggled on and off.

Thanks for the quick response!

I can bubble this functionality up to a CLI flag so it can be toggled on and off.

That would be great.  I looked a little bit at running moon ci for my pre-commit hook, but it's missing --affected and --statusoptions.  In general, I like the idea ofmoon runbeing the all-purpose entry-point while other entry-points likemoon ci` are shortcuts for a particular configuration.

One other thing to note:  unlike moon ci the --summary option for moon run does not display if any tasks fail.  I guess this is a side effect of its "fail immediately" strategy.

One other thing to note: unlike moon ci, the --summary option for moon run does not display if any tasks fail. I guess this is a side effect of its "fail immediately" strategy.

Yeah, pretty sure it is. Will work correctly when everything runs.

Ok, I see what I need to change, so I'll submit a PR for this.
Do you have any thoughts on naming?    I see there's a general desire for one-word CLI flags, because there's an intent to move to kebab_case in 2.0.
Some options:

--noFailFast
--eager
--onFailure <FAIL_ACTION>  (valid modes:  "abort", "continue")
--abort <MODE> (valid modes:  "early", "late")

Instead of aborting immediately, execute as many tasks as safely possible.  Tasks with upstream failures will be automatically failed.

authors: chadrik milesj

repo: moonrepo/moon


text:
Wagtail 2 compatible release

Could you please release a Wagtail 2.x-compatible version? It looks like most of the work has been merged. Thanks!

Changes for the package have indeed been merged but the tests fail because the imports haven't been updated there. I'm happy to submit a PR @robmoorman but I would need to know whether you would rather have:

The tests passing for Wagtail 2.0 and not test previous versions
The tests to pass with all versions of Wagtail (similarly to what we've done with wagtail-django-recaptcha).

Based on https://github.com/moorinteractive/wagtail-bakery/commit/40d388a16eed81434c8f6bed59a84b411d802024 I went ahead with the maximum-compatibility approach: https://github.com/moorinteractive/wagtail-bakery/pull/32

Version 0.3.0 has been released to PyPI, thanks to the contributions of @BertrandBordage, @robmoorman, @stuaxo and @falseperfection 🎉

source: gharchive/issue

authors: loicteixeira ninepints tomdyson

repo: moorinteractive/wagtail-bakery

license: MIT

license_type: permissive

license_source: github-api


text:
Hierarchy support in Zip task

Added hierarchy zipping in Zip task when InputBaseDirectory is provided

Too much hassle for short submit. You probably don't need. Anyone interested in can find changes in my branch Thanks for the review and good starting point. :)

OK. Thanks!

source: gharchive/pull-request

authors: moozzyk neremin

repo: moozzyk/MSBuild-Tasks