Hi everybody,

There were some discussions at #694 with regard to ideas of a possible future major release. GitHub discussions are not too good for these discussions so I decided to open this issue to be more centralized and visible (issues can be pinned).

Also, that probably needs some direction and organization, as having more people involved means we now have different opinions we need to reconcile.

@ghostsquad started working on some ideas on his fork, but I consider that to be a Proof of Concept ™️, and things will likely be different in its final version in the repository.

This issue is a WIP and will be iterated as time passes.

Principles

• Minimal breaking changes
  • Most people should be able to change version: '3' to version: '4' and their Taskfile should keep working mostly the same, with minimal changes
  • This means no unnecessary changes to the schema, like renaming cmds to something else, for example. Most changes should be for new features
  • The same applies to avoiding changes to CLI flags
  • There may be exceptions, of course, but they needs a good justification. Variables will probably be the biggest one, as @ghostsquad has a proposal to make they lazy.
  • Also, for Taskfiles with version: '3' everything should keep working as before, with rare exceptions
  • I'm undecided about remove code related to keep version: '2' working
• Development process
  • Pull requests should be atomic, one for each feature, so they can be reviewed in isolation and discussion can happen with more efficiency about each feature (with regard to UX and implementation)
  • Tests should be written covering the relevant code

Steps

Preparation

• We should try to do this in the master branch IMO, to avoid future conflicts between master and v3
• Code re-organization? We have some old directory structure and may want to improve that
• Tests refactor? Would help as we will write new tests for v3 stuff.
  • Some ideas here: #699

Implementation

• At this point we may decide to have a v3 branch
• Variables refactor
  • Probably the first step, as it's so core an will affects discussions about other changes
  • Make then lazily evaluated (@ghostsquad's proposal, #694)
  • Apply that to ENVs in the process? #693
  • Non-string variables? #140
• Loop / files / matrix
  • Supports looping files? #82
  • Some kind of matrix like GitHub Actions? #675
  • We probably need a proposal to try to solve both use cases
  • #82 is very old but still valid. It's something Make can do that Task still can't
• We need to figure it out if/how to proceed about setup: and hooks proposals: #204, #667, #668
• ...

This is a ongoing document and will be improved...

Hi,

Request

Add the possibility to use import or includes to imports some others tasks. With the default strategy as namespace.

Example

File: docker/v1.0/Taskfile.yaml

version: "2"

task:
  build:
    cmds:
      - docker build...

File: go/v1.0/Taskfile.yaml

version: "2"

task:
  build:
    cmds:
      - go build ...

File (in my project): Taskfile.yaml

imports:
  docker: https://.../docker/v1.0/Taskfile.yaml
  go: file://.../go/v1.0/Taskfile.yaml

— or —

includes:
  docker: https://.../docker/v1.0/Taskfile.yaml
  go: file://.../go/v1.0/Taskfile.yaml

task:
  build:
    - task: "docker:build"
    - task: "go:build"

How to use?

task go:build go:docker

— or —

task build

Finally

What do you think?

UPDATE: This is a general feature request to not run equal dependencies more than once. E.g. if task A and task B both depend on taskC, running both task A and task B in parallel (witin one instance of task), should be able to resolve the dependencies so that taskC is only run once, and this is the interesting port, if it's equal, which we will get to next.

what makes a task equal?

Since you can pass variables to tasks, it's not enough to just look at the name. The best option is probably to rely on a hash of the name + sorted and resolved input variables. A close second could be to rely on unresolved but still sorted input variables, which is not perfect, but could be an acceptable trade-off if it's somehow easier in code.

Original description

I have multiple tasks in my Taskfile that depend on a single task called go-dep that runs the command glide install. When I run task to build multiple targets, I would expect go-dep to be called at most 1 time (zero if it's found to be up-to-date). Instead, I see it's called once for each task that depend on it:

$ task
task: No argument given, trying default task
glide install
glide install
glide install
glide install

PS! go-deps in this case is called with no vars, but the rule should really apply to run a dep at most 1 time when the vars are exactly the same.

I often want to use the directory of where the Taskfile is located as an input to other commands (not the current working directory), but it seems like sprig really locks down access to the filesystem.

Is this possible to do with Task as a first-class idea?

For example, something like:

tasks:
  show-current-dir:
    desc: "show where Task is executing from"
    cmds:
      - echo {{ .TASKFILE_LOCATION }}

Note that this isn't the same as just using $PWD or -d because the working directory might be different; Task should probably provide this as a first-class feature if it doesn't already.

This is a general issue to track proposals with small or big breaking changes, that could be released in the next major version.

This list is a work in progress and can change at any time.

Development is happening on the v3 branch.

Cleanup

• [x] Change module name from github.com/go-task/task/v2 to v3
• [x] Remove all code related support of version 1 (#237)
• [x] Remove automatic inclusion of Taskvars.yml and Taskfile_{{OS}}.yml. This was done before we had a generic inclusion of Taskfiles implemented. We should add options to
  • [ ] Don't include the file if it doesn't exist
  • [x] Allow interpolation on the file name to make it possible to include a OS specific file
• [x] Finally delete the vendor directory? (#214)

Breaking changes

• [x] Added global method: option. Default changed from timestamp to checksum (#246)
• [x] Refactor vars and templates to reduce the number of bugs and undesired behavior (#218)
• [ ] Make CLI arguments override everything (#181) (EDIT: What about #336?)
• [ ] Make up-to-date resolution work when only "generates" is given (#187)
• [ ] Don't run the same dependency (with the same args) more than once by default (#53, #193)
• [ ] Allow forcing specific tasks (#189)

New stuff

• [x] Colored output messages (#207)
• [x] Expose .TIMESTAMP and .CHECKSUM to status: (#216)
• [x] Allow shorter syntax for tasks with default configuration (#194)
• [ ] Allow use as a library (#121)

Documentation

• [x] Mention changes related to method: (shouldn't also check the main guide)
• [x] Update "Taskfile versions" article

There are more issues and feature request that could be added to this release.

For some startup tasks or cleanup paths commands could run in parallel while others should be run in order. Add a Parallel property to task to allow switching between modes

Hi everybody 👋

Once in a while, people ask me why the development is slow, questions got unanswered, bug reports are not responded, features not added, PRs not reviewed, etc.

The answer is simple: the project has grown to become bigger than I ever expected. With a full time job and a life outside work, I have limited time to dedicate to this project. More demand is generated from users than I could keep up even if I doubled the time I dedicate to this project.

So first of all I'd like to ask for your patience and understanding.

Secondly, I'd like to hear opinions and ideas on how to keep the project moving.

And lastly, I'ld like to ask for some help. I had two other people with write access to the repo in the past, but they quickly lost interest in the project. Other than that short period, I've being alone. You could help:

1. Answering questions, validating bug reports, giving opinions on feature requests, closing issues/PRs when they do not make sense, etc.
2. Writing code and reviewing pull requests, specially bug fixes and small features. (I'd still like to have the final word on bigger features as sometimes people suggest changes that breaks backward compatibility or add more complexity than desired)
3. Some people have helped the project by contributing to mvdan/sh as well, and I'm thankful for that. Help on mvdan/sh#93 in particular would hugely benefit Windows users if you're interested to help.

Adding a --summary flag for task to get more a summary of the task

See #107

New field in task called summary

version: '2'
tasks:
  release:
    deps: [build]
    summary: |
      Release your project to github

      It will build your project before starting the release it.
      Please make sure that you have set GITHUB_TOKEN before starting.
    cmds:
      - your-release-tool
  build:
    cmds:
      - your-build-tool

Output for task --summary release:

task: release

Release your project to github

It will build your project before starting the release it.
Please make sure that you have set GITHUB_TOKEN before starting.

dependencies:
 - build

commands:
 - your-release-tool

Behaviour:

• --summary will not execute the task
• --summary will display the summary of a task (see above)
• --summary will use description as fallback, if summary does not exist
• --summary will output a warning (or information), if no description/summary is present
• --summary will output the dependencies if there are any
• --summary will output the commands if there are any

Tests:

• Because there are a lot of edge-cases I decided to extract out a package (summary), which is completly unit tested with above named edge cases.
• There is an integration like test in task_test.go

Documentation is present for that feature

Does go-task currently offer the option of "passthrough" arguments? For example, if I have currently have a task to run the AWS CLI out of a Docker container:

tasks:
  aws:
    cmds:
      - docker-compose run --rm aws		

Is it possible to have the ability for a command like task aws -- ls s3://my-bucket to be translated to docker-compose run --rm aws ls s3://my-bucket, meaning task will pass through anything after -- to the underlying shell command?

This is a more convenient way to pass extra variables compared to the current approach: task write-file FILE=file.txt "CONTENT=Hello, World!". Currently, using this approach allows me to write task aws CMD="ls s3://my-bucket" but the extra variable definition and quotes creates a lot of friction that I think can be alleviated with my proposal.

If this is not possible, it would be a really nice capability to have in the future.

This is my first proposal to add includeable Taskfiles over http.

The config looks like the following:

includes: 
  moo: 
    path: https://raw.githubusercontent.com/go-task/task/master/Taskfile.yml
    cache: 30s
  foo: https://raw.githubusercontent.com/tonobo/task/master/Taskfile.yml
  hui: 
    path: ./
    flush_includes: yes

References: #98

• Task version: 2.5.1
• OS: Windows 10 Professional (64-bit)
• Example Taskfile showing the issue:

# https://taskfile.dev

version: '2'

tasks:

  a:
    cmds:
      - echo "Task a"
      - echo $PATH

  b:
    cmds:
      - echo "Task b"
      - echo "{{.PATH}}"

  c:
    env:
      PATH: tools
    cmds:
      - echo "Task c"
      - echo $PATH

  d:
    env:
      PATH: tools
    cmds:
      - echo "Task d"
      - echo "{{.PATH}}"

  e:
    env:
      PATH:
        sh: echo "tools;$PATH"
    cmds:
      - echo "Task e"
      - echo $PATH

  f:
    env:
      PATH:
        sh: echo "./tools;$PATH"
    cmds:
      - echo "Task f"
      - echo $PATH

  g:
    env:
      PATH:
        sh: echo "$(realpath ./tools);$PATH"
    cmds:
      - echo "Task g"
      - echo $PATH

Hello. Firstly, thank-you for Task. It has, overall, made my development life easier and more pleasant.

I don't know if the problem I have is a bug or if I simply don't understand the correct way to achieve my goal. I'd like to be able to modify the environment variable PATH (either prepending or appending a project-specific directory to the existing value), but I can't figure out how to do this using the set of commands available within Taskfiles.

To provide context, my Taskfile is for use in building go applications. Some applications (projects) require project-specific build tools/helpers that I place in a top-level tools subdirectory (i.e., <project name>/tools). Note that my Taskfile resides at <project name>/Taskfile.yml. I wish to use the go generate command, which effectively requires that external generation tools be accessible via PATH, so I must add <project name>/tools to PATH before running go generate in the task.

While I'm working in Windows, I'm making effective use of busybox-w32 to provide a fairly comprehensive set of what are otherwise Linux tools, so things like cp, echo and realpath are available. I've also tried this via WSL such that things are more like a real Linux environment, with the same results.

The output I get from the above Taskfile (when run under sh or bash via WSL) is as follows (results in native Windows are the same):

$ task a; task b; task c; task d; task e; task f; task g                                             
echo "Task a"                                                                                        
Task a                                                                                               
echo $PATH                                                                                           
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games             
echo "Task b"                                                                                        
Task b                                                                                               
echo "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"      
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games             
echo "Task c"                                                                                        
Task c                                                                                               
echo $PATH                                                                                           
tools                                                                                                
echo "Task d"                                                                                        
Task d                                                                                               
echo "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"      
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games             
echo "Task e"                                                                                        
Task e                                                                                               
echo $PATH                                                                                           
tools;/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games       
echo "Task f"                                                                                        
Task f                                                                                               
echo $PATH                                                                                           
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games             
echo "Task g"                                                                                        
Task g                                                                                               
echo $PATH                                                                                           
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Tasks a, b, c and d are just simple tests; it's tasks e, f and g that illustrate the real issue. Task e works correctly, prepending tools to the current PATH, but neither f nor g have any effect. Task g is the closest to what I need in terms of operations (i.e., adding the absolute path of a project-specific directory).

I'd greatly appreciate any input you could provide on this issue. Thanks in advance.

Problem

Very often, when we use Taskfile, we want to call commands from some directive, required for this commands.

Current Solution

Currently, we can do this this way:

tasks:
  create:
    cmds:
      - |
        cd "dir1/dir2/dir2
        pwd
        echo "Hello"
        cd ..
        echo "Hello"
        pwd

The problem with this solution, is that we can't use cmd properties (like ignore_errors or vars) for each command separately. We run whole job as one command, so we can't use other feature for taskfile.

The second way we can do this, is by making multiple task commands:

tasks:
  create:
    cmds:
      - task: hello1
      - task: hello2
   
  hello1:
    dir: 'dir1/dir2/dir2'
    cmds:
      - echo "Hello" && pwd
  
  hello2:
    dir: 'dir1/dir2'
    cmds:
      - echo "Hello" && pwd

But this is not ideal way either, because we create new sub-commands only to call them from one another "parent" command, so we making redurant task commands we can avoid creating.

Proposal

We can implement command-level dir definition, like ignore_errors for command:

tasks:
  foo:
    cmds:
      - cmd: echo "Hello from" && pwd
        dir: "directory"

There is a different ways to do it thought. We can save current dir if we assume command are sequential, as we do cd. There is some questions about the api. First of all, its about dir relativeness. We can make:

• dir always relative to the parent (task dir) (1)
• dir relative to last command dir (2)

(1) Example:

# dir: src
tasks:
  foo:
    cmds:
      - cmd: echo "Hello from" && pwd # Hello from src/directory
        dir: "directory"
      - cmd: echo "Hello from" && pwd # Hello from src/directory2
        dir: "directory2" 

(2) Example:

# dir: src
tasks:
  foo:
    cmds:
      - cmd: echo "Hello from" && pwd # Hello from src/directory
        dir: "directory"
      - cmd: echo "Hello from" && pwd # Hello from src/directory/directory2
        dir: "directory2" 

And then:

• dir as cmd child (3)
• dir as cmds child (4)

(3) Example:

# dir: src
tasks:
  foo:
    cmds:
      - cmd: echo "Hello from" && pwd # Hello from src/directory
        dir: "directory"
      - cmd: echo "Hello from" && pwd # Hello from src/directory/directory2
        dir: "directory2" 

(4) Example:

# dir: src
tasks:
  foo:
    cmds:
      - dir: "directory"
      - echo "Hello from" && pwd # Hello from src/directory
      - dir: "directory2" 
      - echo "Hello from" && pwd # Hello from src/directory/directory2

So as you can see, there is 4 variations: we need to chose (1) or (2), with (3) or (4).

I think best combination down there is "(2) + (4), because it seems to me, that in many use cases you want to run multiple commands in one dir change. Also, in this variation, dir would be semantically familiar to console cd command:

# dir: src
tasks:
  foo:
    cmds:
      - dir: "directory"
      - echo "Hello 1" 
      - echo "Hello 2" 
      - echo "Hello 3" 
      - dir: ".."
      - echo "Hello 4" 
      - echo "Hello 5" 

We can name this "cd" as command, to make this more semantically correct:

# dir: src
tasks:
  foo:
    cmds:
      - cd: "directory"
      - echo "Hello 1" 
      - echo "Hello 2" 
      - echo "Hello 3" 
      - cd: ".."
      - echo "Hello 4" 
      - echo "Hello 5" 

In case of having task-level dir, with cd we will start moving relative to task-level dir:

# dir: src
tasks:
  foo:
    dir: "directory1"
    cmds:
      - cd: "someDir2" # directory1/someDir2 
      - echo "Hello 1"
      - echo "Hello 2" 
      - echo "Hello 3" 
      - cd: "someDir3" # directory1/someDir2/someDir3
      - echo "Hello 4"
      - echo "Hello 5" 

Not sure if this is intended behaviour when double nesting included taskfiles or not. Example below:

Base Taskfile includes another Taskfile in the tasks subdirectory.

# Taskfile.yml
version: '3'

includes:
  included: ./tasks/included.yml

Included Taskfile includes a utility Taskfile using the new internal keyword. It then defines 2 tasks. One to print the current directory and one to call a task in the util Taskfile that also prints its current directory.

# tasks/included.yml
version: '3'

includes:
  util:
    taskfile: ./util.yml
    internal: true

tasks:
  pwd:
    cmds:
      - pwd

  util-pwd:
    cmds:
      - task: util:pwd

# util.yml
version: '3'

tasks:
  pwd:
    cmds:
      - pwd

Output:

❯ task included:pwd
task: [included:pwd] pwd
/abs/path/to/project

❯ task included:util-pwd
task: [included:util:pwd] pwd
/abs/path/to/project/tasks

The utility Taskfile is getting the working directory of the included Taskfile not the root Taskfile. I can work around this by doing something like this in the included Taskfile:

includes:
  util:
    taskfile: ./util.yml
    internal: true
    dir: ../            # <-- fixes problem

This isn't really a problem per se, but it wasn't what I was initially expecting and was wondering if this is the intended behaviour or not. Obviously, any change here would be a breaking one.

• Task version: 3.18
• Operating System: Linux

Based on https://discord.com/channels/974121106208354339/1042886315856892015 we had the following observations:

• Enabling GHA grouping via output: group does disable progressive stdout streaming. This can be problematic if user has a long-running single script, as he would get zero output on the web console
• GHA allows streaming when grouping is used
• By adding interactive: true to a specific command, we can avoid unexpected combination from parallel task executions
• interactive: true cannot be defined at top level and adding it to each individual command from each individual task adds too much noise to config
• A considerable number of users may not need parallel task runs
• Maybe we can we enable GHA output grouping without having to customise Taskfiles? (detect GH specific env vars)

Feedback welcome to this ticket, especially as we do not know exactly what would the optimal behavior.

a new --json flag works only with the --list and --list-all flags to format those task lists as JSON output.

• can't use --json by itself:

go run ./cmd/task --taskfile ./testdata/output_group/Taskfile.yml hello --json | jq .
task: --json only applies to --list or --list-all
exit status 1

• --json --list ignores tasks that are missing descriptions:

go run ./cmd/task --taskfile ./testdata/output_group/Taskfile.yml hello --json --list | jq .
{
  "tasks": []
}

• --json --list-all includes all tasks

go run ./cmd/task --taskfile ./testdata/output_group/Taskfile.yml hello --json --list-all | jq .
{
  "tasks": [
    {
      "name": "bye",
      "desc": "",
      "summary": "",
      "up_to_date": false
    },
    {
      "name": "hello",
      "desc": "",
      "summary": "",
      "up_to_date": false
    }
  ]
}

this PR includes a temporary WIP (work in progress) commit with additional detail printed to the console around the three failing tests; this commit is intended to help illustrate what is happening when these tests expect that we print nothing to the console so that we can review and confirm that we want to fix the code to maintain that expectation or perhaps update the expectation to provide more detailed output to clients and users.

may resolve #764

I'd love to use task as the task runner in a Python project without requiring developers to install task manually. In my opinion, it is much better to use task over the plethora of language-specific task runners because it tends to be more feature-rich than many alternatives (as far as I can tell) and can be used for projects independent of their programming languages across all major operating systems without requiring a runtime (like the Python interpreter) thanks to the compiled Go binaries. I'd hope that task would gain further adoption with additional language-native packages and development efforts would focus on this project rather than being scattered across the language-specific alternatives.

I believe a Python package could be created quite easily with some inspiration from the following projects:

• https://github.com/shellcheck-py/shellcheck-py
• https://github.com/editorconfig-checker/editorconfig-checker.python

Would you be open to accepting a contribution that adds support for publishing a Python package?

Related to #870.

Problem:

The directive label's function is to allow a task to output a text string, other than the task name when the task is executed.

In the official documentation states that label:

'Overrides the name of the task in the output when a task is run. Supports variables.'

If the label directive is set for a task, say to Hello with label: 'Hello' and the directive output: prefixed is also included in the Taskfile, the output is not as expected.

Further, the outcome is the same if the label text is set dynamically using a Task variable.

See the section 'Analysis' below.

Test Taskfile.yml

The Taskfile below contains two tasks one where label is a static string and one task where the label is from a dynamically loaded task variable.

	version: '3'
	
	output: prefixed
	
	vars:
	  VERSION: '0.2'
	  BACKUP_TIME:
	    sh: date +"%Y-%m-%d_%H:%M:%S"
	  SYSTEM_ID:
	     sh: |
	         hostname
	  BACKUP_ID: '{{.SYSTEM_ID}}_{{.BACKUP_TIME}}'
	
	tasks:
	  default:
	    # Predefined string for label
	    label:   'Hello'
	    desc: Display Task variables
	    cmds:
	      - |
	        echo "HostName:"{{.SYSTEM_ID}}
	        echo "Backup_Time:"{{.BACKUP_TIME}}
	        echo "Backup ID:" {{.SYSTEM_ID }}{{.BACKUP_TIME}}
	        echo "Version:" {{.VERSION}}
	
	  dynamic:
	    # Dynamic string for label
	    label: '{{.BACKUP_ID}}'
	    desc: Display Task variables with label set dynamically
	    cmds:
	      - |
	        echo "HostName:"{{.SYSTEM_ID}}
	        echo "Backup_Time:"{{.BACKUP_TIME}}
	        echo "Backup ID:" {{.SYSTEM_ID }}{{.BACKUP_TIME}}
	        echo "Backup ID 2:" {{.VERSION}}

Output Generated and expected

Output generated from the task default:

	task: [Hello] echo "HostName:"MBP.local
	echo "Backup_Time:"2022-11-14_13:41:47
	echo "Backup ID:" MBP.local2022-11-14_13:41:47
	echo "Version:" 0.2
	
	[default] HostName:MBP.local
	[default] Backup_Time:2022-11-14_13:41:47
	[default] Backup ID: MBP.local2022-11-14_13:41:47
	[default] Version: 0.2

Output expected from the task default:

	task: [Hello] echo "HostName:"MBP.local
	echo "Backup_Time:"2022-11-14_13:41:47
	echo "Backup ID:" MBP.local2022-11-14_13:41:47
	echo "Version:" 0.2
	
	[Hello] HostName:MBP.local
	[Hello] Backup_Time:2022-11-14_13:41:47
	[Hello] Backup ID: MBP.local2022-11-14_13:41:47
	[Hello] Version: 0.2

Output generated from the task dynamic:

	task: [MBP.local_2022-11-14_13:42:39] echo "HostName:"MBP.local
	echo "Backup_Time:"2022-11-14_13:42:39
	echo "Backup ID:" MBP.local2022-11-14_13:42:39
	echo "Backup ID 2:" 0.2
	
	[dynamic] HostName:MBP.local
	[dynamic] Backup_Time:2022-11-14_13:42:39
	[dynamic] Backup ID: MBP.local2022-11-14_13:42:39
	[dynamic] Backup ID 2: 0.2

Output expected from the task dynamic:

	task: [MBP.local_2022-11-14_13:42:39] echo "HostName:"MBP.local
	echo "Backup_Time:"2022-11-14_13:42:39
	echo "Backup ID:" MBP.local2022-11-14_13:42:39
	echo "Backup ID 2:" 0.2
	
	[MBP.local_2022-11-14_13:42:39] HostName:MBP.local
	[MBP.local_2022-11-14_13:42:39] Backup_Time:2022-11-14_13:42:39
	[MBP.local_2022-11-14_13:42:39] Backup ID: MBP.local2022-11-14_13:42:39
	[MBP.local_2022-11-14_13:42:39] Backup ID 2: 0.2

Analysis

The label directive works for both static and dynamic values and does label the first instance of the task name as seen in line 1 of both sets of output.

The label directive does not output the substitute name in the output strings from the echo commands, as requested by output prefixed directive. The output reverts to the task name.

• Task Version 3.17
• Operating System: OS X Version Monterey 12.6