chore(build): add go-task support

[mritd]

add go-task support

Signed-off-by: kovacs mritd@linux.com

[codecov]

Codecov Report

Merging #1608 (97af8e3) into master (9c58278) will increase coverage by 0.28%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1608      +/-   ##
==========================================
+ Coverage   87.86%   88.15%   +0.28%     
==========================================
  Files         104      104              
  Lines        8975     8975              
==========================================
+ Hits         7886     7912      +26     
+ Misses        916      892      -24     
+ Partials      173      171       -2     

Impacted Files	Coverage Δ
pkg/cluster/pool.go	94.82% <0.00%> (+9.48%)	⬆️
pkg/task/pool.go	100.00% <0.00%> (+48.38%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[CLAassistant]

All committers have signed the CLA.

[mritd]

Waiting for PR #1626 to be merged, remove GCC configuration.

[mritd]

@HFO4 PR update completed.

For the github action I haven't changed (I can't test it), it may need you to modify;

By the way, go-task already provides a standard github action installation method: https://taskfile.dev/installation/#github-actions

[HFO4]

Thanks!

[HFO4]

Unfortunately, after detailed tests and estimates, I need to revert this change due to the below considerations:

• go-task does not support env overwrite (Improve how we handle ENV priority (OS vs. .env files vs. Taskfile ENVs). Have a setting or this? go-task/task#693), this will break the existing release pipeline.
• go-task does not support conditional task execution (Add if: keyword to control when a task or command is ran? go-task/task#608), which will make it hard to pack released binaries.

I will try to use goreleaser to implement the current task flow.

[mritd]

I don't understand exactly what it affects.

For the environment variable, if it is obtained through $XXX in the task, it will automatically follow the os environment variable; if the {{.XXXX}} variable is used, it supports task TASK_NAME XXXX=123 way to override.

For the if judgment statement, it can be judged by the environment variable (example: https://taskfile.dev/usage/#os-specific-taskfiles), or by the status option to judge whether it needs to be executed
(https://taskfile.dev/usage/#using-programmatic-checks-to-indicate-a-task-is-up-to-date)

For more complex processing, go-task also supports embedding shell commands to complete.

According to my understanding, goreleaser is only a compilation and release tool, and does not have any task scheduling capabilities.

For github action publishing, after executing task all, all supported platform compilation files will be generated in the release directory, and github action only needs to complete the task of "publishing all files".

[HFO4]

For the environment variable, if it is obtained through $XXX in the task, it will automatically follow the os environment variable; if the {{.XXXX}} variable is used, it supports task TASK_NAME XXXX=123 way to override.

What you're describing is "variables" not "environment variables".

For the if judgment statement, it can be judged by the environment variable (example: https://taskfile.dev/usage/#os-specific-taskfiles), or by the status option to judge whether it needs to be executed
(https://taskfile.dev/usage/#using-programmatic-checks-to-indicate-a-task-is-up-to-date)

This will make the taskfile extremely complicated. The goal is simply: archive binaries to .tar.gz or .zip based on its target OS. Goreleaser can simply achieve since it has built-in archive support.

For more complex processing, go-task also supports embedding shell commands to complete.

That would make no improvement compared to original shell script approach.

According to my understanding, goreleaser is only a compilation and release tool, and does not have any task scheduling capabilities.

We don't need task scheduling capabilities in goreleaser since it has all features we needed for packaging Cloudreve.

For github action publishing, after executing task all, all supported platform compilation files will be generated in the release directory, and github action only needs to complete the task of "publishing all files".

We still need to archive it to .tar.gz or .zip. Yes, we can surely implement this with go-tasks + shell script, but that will make go-task no advantages compared to the old way.