andy5995

I've updated the example. Using this, the mod will build when you push any new commits to your main (default) branch, or any time a pull request is opened or updated. The artifact will get uploaded to the workflow output page (where you can download it and inspect it if desired). You can see at this link near the top right: And at the bottom of the page is a zip file containing the mod (artifact). If the event that triggered the workflow is the creation of a tag starting with 'v', the pyromod gets built and uploaded to the release page (behavior that was in the original example). name: Build Pyromod on: push: branches: - main tags: - v** pull_request: branches: - main env: MOD_NAME: <your-mod> jobs: build-pyromod: if: ${{ github.ref_type != 'tag' }} runs-on: ubuntu-latest env: MOD_VERSION: ${{ github.sha }} steps: - uses: actions/checkout@v3 - uses: 0ad-matters/gh-action-build-pyromod@v1 with: name: ${{ env.MOD_NAME }} version: ${{ env.MOD_VERSION }} id: build-pyromod - name: Upload Artifacts # Uploads artifacts (combined into a zip file) to the workflow output page uses: actions/upload-artifact@v3 with: name: ${{ env.MOD_NAME }}-${{ env.MOD_VERSION }} path: "output/${{ env.MOD_NAME }}*.*" release-pyromod: if: ${{ github.ref_type == 'tag' }} runs-on: ubuntu-latest env: MOD_VERSION: ${{ github.ref_name }} steps: - uses: actions/checkout@v3 - name: Massage Variables run: | echo "MOD_VERSION=${MOD_VERSION:1}" >> $GITHUB_ENV - uses: 0ad-matters/gh-action-build-pyromod@v1 with: name: ${{ env.MOD_NAME }} version: ${{ env.MOD_VERSION }} id: build-pyromod - name: Create sha256sum run: | OUTPUT_FILE="$MOD_NAME-$MOD_VERSION.pyromod" cd output sha256sum $OUTPUT_FILE > $OUTPUT_FILE.sha256sum - name: Release PyroMod uses: ncipollo/release-action@v1 with: allowUpdates: True prerelease: False artifacts: "output/${{ env.MOD_NAME }}*.*" token: ${{ secrets.GITHUB_TOKEN }} omitNameDuringUpdate: True omitBodyDuringUpdate: True

1.x.x releases will point to v1 from now on. So your "uses" line should look like `- uses: 0ad-matters/gh-action-build-pyromod@v1` until v2 is released. https://michaelheap.com/semantic-versioning-for-github-actions/ https://github.com/actions/toolkit/blob/master/docs/action-versioning.md#versioning

Oh, yeah I get that when I just run ActorEditor normally. So I haven't tried to do anything about it with the appimage. Thanks for confirming the fix @hyperion. I'm merging the PR to trunk, which means a new release will show up soon. But you don't need it if you have the artifact. The only difference will be the filename.

@hyperionI've made a couple changes. Could you try the artifact at https://github.com/0ad-matters/0ad-appimage/actions/runs/3199921391 (The zip file at the bottom)

@hyperionI'm using Manjaro, and it appears that pango is packaged so that libthai is a dependency (explaining why I have it installed even though I don't speak Thai either). Can you temporarily install libthai, re-run ActorEditor to see if there are any other missing dependencies? I'm building the appimage with linuxdeploy, and it's got this option: `--library=[library...] Shared library to deploy` so I can try to specify libthai and any other commonly-missing deps.

Someone recently asked me in a chat about release-type stuff: Here's what I said: I generally have a different philosophy about release cycles. But it also depends on what's involved in doing a release. But what I usually do with rmw, if I make a bug fix that's a significant improvement (even if it's not a critical flaw or security risk) and would be helpful to users, I do a release. a bugfix or a nice new feature For minor changes that I think the majority of users won't care about or need, I wait. But the time it takes to do packaging and update docs for a release is also a consideration. I released my first software back around 2004, using SourceForge. I read there the suggestions they had about releases, and I guess I still kind of follow it: "Release early, release often" I say, if there are no known security flaws or new bugs, and there are some good improvements, release, so users can enjoy the changes, and the devs can get feedback. Another advantage is that any time a release happens, the project gets more active and more visible for a temporary time afterward.

@hyperionwhich distro do you use. I added some new info to the ticket Just curious, do you have 'libthai.so.0' on your system, but in a different location than where the appimage is looking for it?

@hyperionThanks for letting me know. Ticket created I'm glad the game part is working for you. Thanks for the feedback.

I pushed some changes so now `ActorEditor` will be accessible by using a symlink. As noted on README.md now: cd /path/to/<Appimage-File> ln -s <Appimage-File> ActorEditor The new images should be on the release page in about an hour. cc @hyperion@Stan`

Anyone who tried the a26 appimage and got **libc errors** should try the newer a26 appimage at https://github.com/0ad-matters/0ad-appimage/releases/tag/v0.0.26-alpha (Though no errors like that have been reported yet)

@KampotI'm glad you got it working! Since you're new to GitHub, I can understand how it could be confusing. It's the very first github action I made, and I've been using GitHub for several years. I know you've already looked at the files in the build-pyromod repo. If you look at some of the links in the README, it might help you understand better. They key element is the use of docker with the action. Note that Docker isn't required to make an action, but it can be very helpful. If at some point you have some specific questions about how it's done, feel free to post here. Good luck!

@KampotI made a couple mistakes in my docs. The release action should be 'ncipollo/release-action@v1` not `ncipollo/release-action@v1.1`

I've also updated the README with some extra info. Thanks for the suggestion @smiley

I can try to make things a bit more clear, but I'm not sure a tutorial is warranted at this point. There's already docs on building a pyromod, github actions, and docker. So... this thread is intended for anyone who hosts a mod on GitHub and want a bit of convenience when doing a release. Or this thread is intended for anyone thinking about hosing a mod on GitHub. People who don't use GitHub to mod will have no use for this action and can safely ignore this thread. The docs for using the Action on the repo README. It assumes the root directory of your mod is in the repo root (e.g., the repo root is where 'mod.json' is located) When the action runs, it will create the mod using the pyrogenesis archive builder as shown here, and output the resulting .pyromod file to $PWD/output. An example is shown on the README on how to access it so it can be used in a separate release action. The release action shown in the example is not required to use the gh-action-build-pyromod action (there are other release actions available on GitHub that can be used instead, if you prefer) No technical knowledge of Docker is needed to use the Action. I posted this for anyone who is curious about the docker image used "behind-the-scenes" for the action, or for anyone who wants to "audit" how the image is created, or make a PR to improve upon it. I'd be happy to answer any specific questions related to the Action. How's that @smiley?

Ticket 6622 created @sarcoma@Freagarach@Stan`

The Dockerfile I'm using for the Action is at 0ad-matters/0ad-bin-nodata

@kun0AppImage for Linux is at https://github.com/0ad-matters/0ad-appimage/releases/tag/v0.0.26-alpha @Stan`

I've made a GitHub action that builds a pyromod. It does it using the 'pyrogenesis' archive builder so converts the textures and stuff.

No, actually the idea just popped into my head one day ("instead of writing a lot of code to alter the bot's behavior, why not just make one civ OP?")

This is on 0ad.mod.io now and downloadable from the mod center if you're using a26. (cc @Norse_Harold)

This is on 0ad.mod.io now and downloadable from the mod center if you're using a26.

Presently using linuxdeploy to create an appimage, there's no option to disable compression. I've opened a ticket about that on the appimage plugin repo here. Someone familiar with how 0ad decompresses the data at runtime want to comment or have a look @Stan`@vladislavbelov

@logandavidNot yet. The first problem I noticed was voice chat doesn't work. In the settings, I can grant permissions to my audio devices, but the settings are immediately lost. Welcome to the forum.

I added some info to the build instructions about using distcc to speed up build times. I see that using distcc has been mentioned here before:

@Old RomanGood feedback, thank you! I've slowed down the pace of the stone and metal in the git version, so those changes will be included with the next release, which will probably happen within a week or two.