Infinity Auto Packager - automatically generate mod packages when you publish a release

ALIEN

Infinity Auto Packager

What does this tool do?
A tool that automatically generates Infinity Engine mod packages when you publish a release.

What are Infinity Engine mod packages?
They are standardized, universal and cross-platform Infinity Engine Mod Packages

• .zip package
  It contains the latest WeiDU executable for Windows and macOS (for Linux is impossible) and .command file for macOS.
• .iemod package
  The IEMOD format is intended to be a platform-independent distribution format for modifications for games using the Infinity Engine. The .iemod packages are used mainly by mod managers. Among other things, they offer a "double-click at file>extract>install" feature.

General info

• can be combined with the ModRelease tool
• the package name is taken from mod metadata ini file
• the package version is taken directly from the tp2 file
• packages always have the latest WeiDU version, at the time when they were created
• the tool is a serverless microservice - it will work as long GitHub Actions will exist in any form

Example: ( repository )



How to do the one-time installation inside your mod repository?
- by adding to the repository

1. Mod directory structure: Example\Example.tp2
2. Git repository structure: must have a top-level mod data folder

   Example\...
   Example\Example.tp2
   README.md
   

3. Download Infinity Auto Packager repository, extract InfinityAutoPackager-master.zip file
4. Copy '.github' folder into your mod repository
5. Commit and push changes to the remote repository

- by using the Github webpage directly

1. Open the main page of your mod, locate the "Create new file" button
   
2. Paste this into the filename

   .github/workflows/InfinityAutoPackager.yaml
   

   , do not skip dot at the beginning
   
3. Open "Infinity Auto Packager" file, copy all content and paste it into the editor, then click "Commit new file" in order to save changes
   

How to use it?

1. Publish release

After a few moments, the .iemod and .zip packages will be automatically created and added to the published release. How long it takes depends on how big the mod is.

If you have additional questions, feel free to ask

_Luke_

Thank you, it's much appreciated!

Is this meant to automate the creation of a Windows / macOS / Linux package of the mod in question?

ALIEN

Luke93 wrote: »

Thank you, it's much appreciated!

Is this meant to automate the creation of a Windows / macOS / Linux package of the mod in question?

Yes. The .zip package contains weidu executable for Windows and macOS (for Linux is impossible) and .iemod has no executables because Mod Managers handle them. I've added this info to the first post.

Gwendolyne

Official SHS Github account is using it for a while, and it works fine. So don't be afraid to test it.

jastey

This looks really cool. Thank you so much for your work, @ALIEN !

Although I have the slight suspicion that this might be part of your efforts to bringing modders to upload their mods to GitHub.

ALIEN

jastey wrote: »

This looks really cool. Thank you so much for your work, @ALIEN !

Although I have the slight suspicion that this might be part of your efforts to bringing modders to upload their mods to GitHub.

Ha! It looks like but I will also release the 'local' version of this tool for people who just want to have nice packages uploaded whenever they want

Anyway, I'm glad that you enjoy it, given the number of mods which you modernized and updated.

jastey

Hi @ALIEN ! First, let me thank you for this tool. I watched the mod packages pop up in the SHS repos where @Gwendolyne integrated the tool and it felt really good!

But apparently, adding a folder to my repo to make the tool work is too complicated for me. Would you have a look at why the packages do not get added to the new I4E release here? Help would be very appreciated.

ALIEN

@jastey You installed the tool correctly. It's GitHub who's stuck on "Starting your workflow run..." as you can see it here: https://github.com/Gibberlings3/Imoen4Ever/runs/1084930657?check_suite_focus=true

Can you open https://github.com/Gibberlings3/Imoen4Ever/settings/actions and see if "Enable local and third-party Actions for this repository " is enabled?

jastey

Thanks for the quick answer. Unfortunately I do not have the rights to see these settings. I'm contacting G3 admins currently.

jastey

@ALIEN

Can you open https://github.com/Gibberlings3/Imoen4Ever/settings/actions and see if "Enable local and third-party Actions for this repository " is enabled?

It is enabled and it also was enabled before, but I didn't have admin rights when I integrated the .github/workflows folder, maybe that was the problem?

ALIEN

@jastey No, only 'Write' rights are necessary.
I need you to perform some diagnostic:

- Try to create a 'test' release inside you fork repo: https://github.com/Gitjas/Imoen4Ever/releases - it should definitely work for you.

If that will work, you need to 'republish' v5beta release of the Gibberlings3/Imoen4Ever:

1. Remove current 'execution of the Infinity Auto Packager', nothing is really lost, it's just cleanup


2. Edit v5beta release: https://github.com/Gibberlings3/Imoen4Ever/releases/edit/v5beta
3. Remove the associated tag from the release:

and click 'Update release'. That way, the release will be set as 'Draft'.

4. Open 'v5beta draft release' again, set 'v5beta' tag again and click 'Update release'
5. The release should be republished again and the new execution of the Infinity Auto Packager should trigger

Let's hope that it was a temporary hangup on the GitHub side.

jastey

@ALIEN thank you for the suggestions. I did so, but the workflow does not get started anew: https://github.com/Gibberlings3/Imoen4Ever/actions
Maybe it is because G3 GitHub is an organization and I am not an Owner? You already said that writing rights should suffice, I'm just guessing because it was no problem to tag a test release in my own GitHub Repo.
I'll come back to this after I tagged a new release at G3 in the future.

jastey

@ALIEN wohoo, it worked now: https://github.com/Gibberlings3/Imoen4Ever/releases/tag/v5Beta0.2

ALIEN

@jastey Yep, probably it was a temporary issue.

For the record, in case this error will occur again: you don't have to create a new release/new tag. You just have to follow the instructions above. The release can be set to 'Draft' and published again or deleted and recreated in order to trigger the new attempt to create packages.

jastey

@ALIEN I did the suggestion with setting it to draft and re-releasing it (twice), but it didn't (re)start the workflow in my case.
The Beta 0.2 contains fixes so that was no extra work in that case.

jastey

@ALIEN I am still appreciating the work this tool saves me. Thank you again for your work on this.

I am a bit unhappy with the naming scheme of it, though. That or I am doing something wrong when versioning my releases.

For example, for this repository the automated generated packages (for this version) ended up having the name "-veaob.1.zip" and "-veaob.1.iemod". I uploaded a renamed package by hand.

For this repository, the name (for this version) became "grey-the-dog-npc-for-bgt-bgeesod-bgiiee-and-eet-5.zip" which is a bit long.

I assume the tool goes for something like repo name+version number, so I am not sure what happened in these instances.

Do I need to do something differently or is this something you can fix on your end? Is there an error in the InfinityAutoPackager.yaml I am using maybe?

Gwendolyne

The first part of the release name is taken from the mod.ini name keyword:

Name = Grey the Dog NPC for BGT, BG:EE(SoD), BGII:EE, and EET

If the ini file does not exist, I guess it takes the mod folder name.

jastey

@Gwendolyne ah, that makes a lot of sense. I wasn't aware it takes the name from the .ini, I thought it uses the Repo name somehow.
So the Grey mod name was because I chose a stupid mod name in the .ini and the name for BST was because I forgot to put in an .ini yet. @ALIEN I can live with that.

ALIEN

@jastey

Gwendolyne is right, it takes the name from ini. I already saw that you have altered 'Grey the Dog NPC', added new guidelines to the wiki.

My motivation for use ini was to skip 'yet another place' where you would need to provide 'customized package name'

BTW: That version name for "Balduran's Seatower" mod is really awful. It doesn't mean anything. It should be number with 'alpha' or 'beta' to give players some indication of what they are dealing with.

jastey

ALIEN wrote: »

BTW: That version name for "Balduran's Seatower" mod is really awful. It doesn't mean anything. It should be number with 'alpha' or 'beta' to give players some indication of what they are dealing with.

EAOB stand for Early Access Open Beta, which people know when they download the mod after reading the full version title.
Besides, naming it alpha/beta.xy wouldn't have helped with the name the Infinity Auto Packager gave the packages which lacked the actual mod name.

ALIEN

@jastey Point taken, I'm nitpicking too much.

jastey wrote: »

Besides, naming it alpha/beta.xy wouldn't have helped with the name the Infinity Auto Packager gave the packages which lacked the actual mod name.

That's a bug and it will be fixed.

AstroBryGuy

@ALIEN - I'm new to working with GitHub workflows. I want to tweak the workflow to copy the README.md file from the main folder of the repository into the mod folder for packaging (i.e., so I don't need to maintain two copies of the README).

Any advice on how to add that to the workflow?

Thanks!

EDIT: Nevermind! Solved it!

name: copy readme
on: [push]
jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: copy file with args
      uses: canastro/copy-file-action@master
      with:
        source: "README.md"
        target: "ChattyImoen/README.md"
        flags: "-f"
    - name: Commit files
      run: |
        git config --local user.email "action@github.com"
        git config --local user.name "GitHub Action"
        git add ChattyImoen/README.md
        git commit -m "Add changes" -a
    - name: Push changes
      uses: ad-m/github-push-action@master
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}

ALIEN

@AstroBryGuy Hey! This is a very nice solution, which doesn't interfere with Infinity Auto Packager, congrats man!

I've played with it a bit and come up with a general solution that runs only when README.md file is modified and doesn't require constant modification of 'MOD_FOLDER' name. It should work for standard mod directory structure aka: MyMod/MyMod.tp2.

name: Copy README.md

on:
  push:
    paths: 'README.md'
  workflow_dispatch:

jobs:
  CopyREADME:
    if: github.ref_type != 'tag'
    name: Copy README.md
    runs-on: ubuntu-latest
    permissions: write-all
    steps:
      
      - name: Checkout repository
        uses: actions/checkout@master
        
      - name: Find tp2 file
        uses: ab185508/file-type-finder@v1.0.0
        id: findtp2file
        with:
          path: "/"
          type: ".tp2"
      
      - name: Get mod folder name
        uses: JungWinter/split@v2.1.0
        id: split
        with:
          separator: '''' # split by two single quote characters 
          msg: ${{ steps.findtp2file.outputs.names }}
      
      - name: Copy README.md into mod folder
        uses: canastro/copy-file-action@master
        with:
          source: "README.md"
          target: "${{ steps.split.outputs._1 }}/README.md"
          flags: "-f"

      - name: Git add & commit
        uses: EndBug/add-and-commit@v9.1.3

AstroBryGuy

@ALIEN - Thank you! Your GitHub workflow skills are awesome!

ALIEN

Infinity Auto Packager 2.0.0:
https://www.gibberlings3.net/forums/topic/31131-infinity-auto-packager-automatically-generate-mod-packages-when-you-publish-a-release/?do=findComment&comment=328230