Loaders as an array

[Faboslav]

Description

Hello there, i am trying to do little bit more complex action on my side, my github (matrix)context is like the following for this specific run:

2024-01-20T13:23:49.7956867Z   workflow-job-context: {
  "branch": "1.19.2",
  "mod_loader": "fabric",
  "supported_mod_loaders": [
    "fabric",
    "quilt"
  ],
  "curseforge_id": "779833",
  "modrinth_id": "ECOSu6pa"
}

If i want to use mentioned supported_mod_loaders in the loaders field as following:
${{ matrix.supported_mod_loaders }} it doesnt work with error:
Error: The template is not valid. .github/workflows/publish.yml (Line: 139, Col: 30): A sequence was not expected.

Expected Behavior

Mentioned in general description.

Actual Behavior

Mentioned in general description.

Version

3.3.0

Environment

GitHub Actions

Configuration

No response

Logs

No response

Other Information

No response

[Kir-Antipov]

Hallo! This is not a bug, nor a problem on the side of mc-publish.

Error: The template is not valid. .github/workflows/publish.yml (Line: 139, Col: 30): A sequence was not expected

This an error message from GitHub telling you that your workflow file is invalid.

I assume that this is the workflow in question.

Note that supported_mod_loaders is defined as a proper array:

supported_mod_loaders: [fabric, quilt]

The problem is you try to provide it as an input to a GitHub Action (which just happens to be mc-publish) as is. GitHub only allows strings and "stringifiable" values to be used within this context. So, if a complex object, like an array, is provided, GitHub will immediately fall flat on its back and spit a completely unhelpful error in your face.

Therefore, before providing any value to any action (once again, the problem is not limited to mc-publish), you need to ensure that it's a string.

If you check the loaders input in the README, you'll find the following example there:

loaders: |
  fabric
  forge
  quilt

As you can see, this is not an array; it's a multiline string. It's not because I prefer working with strings over proper arrays and other complex objects, but rather because GitHub restricts action developers from receiving anything other than strings. Thanks to yet another brilliant decision at Microsoft, we find ourselves having to do double the amount of work:

• You need to convert a perfectly fine array into a string.
• I, on the other hand, need to convert that string back into the array you originally intended to provide.

But, well, it is what it is. To convert an array you obtained from the matrix to a string, you can use the following syntax:

loaders: ${{ join(matrix.supported_mod_loaders, ' ') }}

Hope this helps! :)

[Kir-Antipov]

One thing, though - it's strange that \n is rendered in the log. It's possible that GitHub doesn't support escape sequences in its expressions; I wouldn't be surprised at this point. If this is the case, you can use a regular space (' ') to separate the loaders. However, be aware that space separators are only allowed for loaders; other inputs require a proper newline sequence to work!

[Faboslav]

What about game-versions, i basically need to do something similar to this, i currently do this: game-versions: ${{ matrix.branch }}\n${{ matrix.secondary_game_version }}?

[Kir-Antipov]

So, I've examined the logs of your latest run, and it appears that the issue regarding GitHub's inability to interpret escape sequences as intended is indeed valid:

loaders: fabric\nquilt
game-versions: 1.20.4\n1.20.3

So, replace

loaders: ${{ join(matrix.supported_mod_loaders, '\n') }}

with

loaders: ${{ join(matrix.supported_mod_loaders, ' ') }}

Additionally, as you just mentioned, you define game-versions as follows:

game-versions: ${{ matrix.branch }}\n${{ matrix.secondary_game_version }}

The problem is... YAML is just weird. In this case, \n is treated as a literal (i.e., "\\n"). Someone on StackOverflow has done an excellent job summarizing the various quirks associated with specifying strings in different ways, you can read about it here, highly recommended.

To fix the game-versions input, consider one of the following options:

game-versions: "${{ matrix.branch }}\n${{ matrix.secondary_game_version }}"

or

# If `secondary_game_version` is always present, you can combine the versions into a range.
# E.g., 1.20.4 || 1.20.5
game-versions: ${{ matrix.branch }} || ${{ matrix.secondary_game_version }}

or

game-versions: |
  ${{ matrix.branch }}
  ${{ matrix.secondary_game_version }}

[Faboslav]

Thank you for your help once again, i have one last question, if i have multiloader setup, will mc-publish detect my meta files? Because if that is the case, maybe it would be better to define these things in the meta files for each mod loader.

[Kir-Antipov]

Thank you for your help once again

I'm always glad to help!

if i have multiloader setup

mc-publish doesn't know anything about it, nor does it care :) The only thing that matters is the files you are actually publishing; mc-publish reads metadata from them, namely from the primary file.

maybe it would be better to define these things in the meta files for each mod loader

Absolutely! Most of the time, you don't even need to specify anything because fabric.mod.json automatically translates into ["fabric"], mods.toml into ["forge"] or ["neoforge"] (depending on the presence of a dependency on neoforge), and quilt.mod.json into ["quilt"]. However, you can always override this behavior by specifying the loaders manually in the mc-publish section of your metadata:

// fabric.mod.json
"custom": {
  "mc-publish": {
    "loaders": ["fabric", "quilt"]
  }
}

# mods.toml
[mc-publish]
    loaders = ["forge", "neoforge"]

[Faboslav]

Here you go: https://github.com/Faboslav/friends-and-foes-beekeeper-hut/blob/master/.github/workflows/publish.yml, it's currently work in progress, but i am testing it step by step and i am currently stuck on this thing.

[Kir-Antipov]

Thanks! I've just finished editing my response, so do check it out. I hope that it solves your problem!

[Faboslav]

Continuing the discussion, strangely enough, with that mentioned publish workflow

On curseforge site, there is only the Quilt mod loader, and fabric api as dependency

On modrinth, there is correctly both fabric and quilt, and also fabric api as a dependency

I am not sure, why is there fabric api even i dont mention that anywhere and if that is based on the mod meta files, why my other required dependencies are not there.

[Faboslav]

Run is available here: https://github.com/Faboslav/friends-and-foes-beekeeper-hut/actions/runs/7596537598/job/20690362618

For example, this is context for 1.19.2 fabric:

with:
    github-token: ***
    github-tag: mc1.19.2-2.0.0
    curseforge-id: 711899
    curseforge-token: ***
    modrinth-id: Kt[4](https://github.com/Faboslav/friends-and-foes-beekeeper-hut/actions/runs/7596537598/job/20690362618#step:9:4)RVKEd
    modrinth-featured: true
    modrinth-token: ***
    name: Friends&Foes - Beekeeper Hut 2.0.0 (fabric)
    version: fabric-mc1.1[9](https://github.com/Faboslav/friends-and-foes-beekeeper-hut/actions/runs/7596537598/job/20690362618#step:9:9).2-2.0.0
    loaders: fabric, quilt
    game-versions: 1.19.2

[Kir-Antipov]

So, the first problem can be identified here:

loaders: fabric, quilt

Where did the comma come from? It turns out a typo has sneaked into your workflow:

- supported_mod_loaders: ["fabric, quilt"]
+ supported_mod_loaders: ["fabric", "quilt"]

Because of that, mc-publish receives ["fabric,", "quilt"] instead of ["fabric", "quilt"]. Thus, only quilt gets correctly parsed, so it is the only loader that gets sent to Modrinth and CurseForge. However, Modrinth performs an analysis on the metadata of your mods, so it seems that it adds the missing fabric automatically.

I am not sure, why is there fabric api even i dont mention that anywhere

But you do? Here are the dependencies listed in fabric.mod.json of the version shown in the screenshot:

"depends": {
  "java": ">=17",
  "minecraft": ">=1.19.3",
  "fabricloader": ">=0.14.21",
  "fabric": ">=0.76.0+1.19.3",
  "friendsandfoes": ">=2.0.7"
}

java is not a mod, minecraft is not a mod, and fabricloader is not a mod. On the other hand, fabric is a mod, and friendsandfoes is a mod too, but it's nowhere to be found.

I don't see anything unexpected in this regard.

[Faboslav]

Yeah, i can see the error, it's there because i messed up while i was making sure, that all the provided variables are represented as string, due to github transforming to 1.20 value to 1.2 thinking it's a number. Thank you very much for all the provided patience and support!

[Kir-Antipov]

You are always welcome :)

[Faboslav]

At this point, it would be very helpful to be able to do some kind of test or dry run on my setup, maybe i can help with that functionality, if wanted

[Kir-Antipov]

Yup, I totally see the reasoning behind that :D

This feature has been requested in #45, and I'm planning to implement it. After all the refactoring that went into v3.3, it's now a matter of implementing a fetch wrapper, which will log all the requests it performs and prevent any non-GET request from propagating, returning some kind of mocked data instead.

While the help is generally appreciated, I believe it is better for me to implement this feature myself, because it requires a good understanding of the nuances of the project and the various platforms it supports.