Publish AppImage to appimage.github.io/

[hiran]

I am puzzled. Did you upload a new AppImage or is it pulling artifacts from the Oolite repo?

I just specified our URL. They do not expect us to upload. Instead they download and grab the metadata to build their catalog. Any user browsing the catalog will download from us.

I like that concept. We are doing the same with OXPs.

My surprise is that their linter all of a sudden passes. We'll need to investigate carefully, or they might extend to also use flatpak metadata in case that was contained.

I'll try to contact someone on their side.

[hiran]

I'll try to contact someone on their side.

Not yet real contact, but additional investigation showed the successful build was due to some changes on a specific branch in their repo.
Two commits seem to relax their linter:
- Allow empty DESKTOP_COMMENT
- Do not error when no license is found

Somehow I hope they did it not for us. We have not yet provided any useful metadata for AppImage and are rightfully blocked there.

I will retrigger the catalog build once we have changed something on our side.

[mcarans]

I'll try to contact someone on their side.

Not yet real contact, but additional investigation showed the successful build was due to some changes on a specific branch in their repo.
Two commits seem to relax their linter:
- Allow empty DESKTOP_COMMENT
- Do not error when no license is found

Somehow I hope they did it not for us. We have not yet provided any useful metadata for AppImage and are rightfully blocked there.

I will retrigger the catalog build once we have changed something on our side.

Have a look at the appimages here: https://github.com/mcarans/oolite/actio ... 3101780478. I have fixed the naming and added to them the required metadata. Are they ok?

The flatpak and appimage share a build step and metadata.

[hiran]

I'll try to contact someone on their side.

Not yet real contact, but additional investigation showed the successful build was due to some changes on a specific branch in their repo.
Two commits seem to relax their linter:
- Allow empty DESKTOP_COMMENT
- Do not error when no license is found

Somehow I hope they did it not for us. We have not yet provided any useful metadata for AppImage and are rightfully blocked there.

I will retrigger the catalog build once we have changed something on our side.

Have a look at the appimages here: https://github.com/mcarans/oolite/actio ... 3101780478. I have fixed the naming and added to them the required metadata. Are they ok?

The flatpak and appimage share a build step and metadata.

Sounds good. Yet to test them I'd have not only to download them but also recreate appimagehub's test environment. So far I do not know how to efficiently do that.

What I can try is to clone their repo. But it still would require to fetch a (pre)release. Would you add that step in your repo and we can test better?

[hiran]

Have a look at the appimages here: https://github.com/mcarans/oolite/actio ... 3101780478. I have fixed the naming and added to them the required metadata. Are they ok?

The flatpak and appimage share a build step and metadata.

Sounds good. Yet to test them I'd have not only to download them but also recreate appimagehub's test environment. So far I do not know how to efficiently do that.

What I can try is to clone their repo. But it still would require to fetch a (pre)release. Would you add that step in your repo and we can test better?

I tried to run the process - but it seems to be hooked into the Github workflow. It downloads a lot of stuff online, and as long as the URL we provide does not contain the correct metadata I can only manually check what might be the case - which I tried.

It looks like the metadata you provide is good. Interpreting the script I get to the point where it's output file is getting generated.

Let's push the changes at least to the OoliteProject/oolite master branch. From there I can trigger a new build in appimagehub and we will see if all is good.

[mcarans]

Have a look at the appimages here: https://github.com/mcarans/oolite/actio ... 3101780478. I have fixed the naming and added to them the required metadata. Are they ok?

The flatpak and appimage share a build step and metadata.

Sounds good. Yet to test them I'd have not only to download them but also recreate appimagehub's test environment. So far I do not know how to efficiently do that.

What I can try is to clone their repo. But it still would require to fetch a (pre)release. Would you add that step in your repo and we can test better?

I tried to run the process - but it seems to be hooked into the Github workflow. It downloads a lot of stuff online, and as long as the URL we provide does not contain the correct metadata I can only manually check what might be the case - which I tried.

It looks like the metadata you provide is good. Interpreting the script I get to the point where it's output file is getting generated.

Let's push the changes at least to the OoliteProject/oolite master branch. From there I can trigger a new build in appimagehub and we will see if all is good.

Are you able to switch the appimagehub to use the 1.92-maintenance branch instead of master? 1.92.1 will be released from that branch not master (which is for 1.93).

[hiran]

Are you able to switch the appimagehub to use the 1.92-maintenance branch instead of master? 1.92.1 will be released from that branch not master (which is for 1.93).

Sounds odd to me. We are trying to fix the release before development?
But let's see.

[...]
How to submit AppImages to the catalog

Create a new file using this link and send a Pull Request.

The file should contain one line with a link to the GitHub repository that hosts AppImages on its Releases page.

Alternatively, a link to the AppImage. Nothing else.
[...]

Either I specify the repo only (which is what I did), or I specify the very AppImage. However the current 1.92 release does not contain the required metadata.
I do not care where you add it first, but without any change on our side any of my attempts will be bound to fail. Not even your personal fork is fit for purpose as you point me to an action run's artifact where I would need a release.

[mcarans]

Are you able to switch the appimagehub to use the 1.92-maintenance branch instead of master? 1.92.1 will be released from that branch not master (which is for 1.93).

Sounds odd to me. We are trying to fix the release before development?
But let's see.

[...]
How to submit AppImages to the catalog

Create a new file using this link and send a Pull Request.

The file should contain one line with a link to the GitHub repository that hosts AppImages on its Releases page.

Alternatively, a link to the AppImage. Nothing else.
[...]

Either I specify the repo only (which is what I did), or I specify the very AppImage. However the current 1.92 release does not contain the required metadata.
I do not care where you add it first, but without any change on our side any of my attempts will be bound to fail. Not even your personal fork is fit for purpose as you point me to an action run's artifact where I would need a release.

Working in a bug fix branch for point updates is normal development practice. If I developed this in the master branch, it will be released in 1.93 at some much later date. By treating it as as a bug fix, it can be worked on in the 1.92-maintenance branch. What I think we need to do is make the build-all step in GitHub Actions also build 1.92-maintenance prereleases, one of which will become the 1.92.1 stable release in future.

[hiran]

Working in a bug fix branch for point updates is normal development practice. If I developed this in the master branch, it will be released in 1.93 at some much later date. By treating it as as a bug fix, it can be worked on in the 1.92-maintenance branch. What I think we need to do is make the build-all step in GitHub Actions also build 1.92-maintenance prereleases, one of which will become the 1.92.1 stable release in future.

Changes to master immediately result in a release tagged "pre-release" so they are immediately available for download. That's why appimagehub can pick them up.

But yes, if the release branch exists currently it is silent - no releases seen. That would explain why I see nothing to work with. Let's change that.

[mcarans]

Working in a bug fix branch for point updates is normal development practice. If I developed this in the master branch, it will be released in 1.93 at some much later date. By treating it as as a bug fix, it can be worked on in the 1.92-maintenance branch. What I think we need to do is make the build-all step in GitHub Actions also build 1.92-maintenance prereleases, one of which will become the 1.92.1 stable release in future.

Changes to master immediately result in a release tagged "pre-release" so they are immediately available for download. That's why appimagehub can pick them up.

But yes, if the release branch exists currently it is silent - no releases seen. That would explain why I see nothing to work with. Let's change that.

I tried changing my fork to

Code: Select all

if: github.ref == 'refs/heads/master' || endsWith(github.ref, 'maintenance')

This build https://github.com/mcarans/oolite/actio ... 3132368353 produced a tagged prerelease https://github.com/mcarans/oolite/relea ... 16-334d25a

Will that tagged prerelease work with appimagehub?

[Lone_Wolf]

Working in a bug fix branch for point updates is normal development practice. If I developed this in the master branch, it will be released in 1.93 at some much later date. By treating it as as a bug fix, it can be worked on in the 1.92-maintenance branch.

Usually that method is only used for bugs that are in stable but not in master.
To ensure bugs that affect master & stable are fixed in both the normal approach is to solve them in master and backport the fix to stable branch.

[hiran]

Usually that method is only used for bugs that are in stable but not in master.
To ensure bugs that affect master & stable are fixed in both the normal approach is to solve them in master and backport the fix to stable branch.

I'd follow the same practice.

[mcarans]

Working in a bug fix branch for point updates is normal development practice. If I developed this in the master branch, it will be released in 1.93 at some much later date. By treating it as as a bug fix, it can be worked on in the 1.92-maintenance branch.

Usually that method is only used for bugs that are in stable but not in master.
To ensure bugs that affect master & stable are fixed in both the normal approach is to solve them in master and backport the fix to stable branch.

That is true but I already have major changes in my master branch to change the build such that there are no download steps during the build as per another_commanders requirements. I put that work on hold temporarily to look at the requests to fix things in 1.92.

It would make merge hell for me to try to make another branch off master with changes that affect similar files and I'm already getting fed up that I am not working on the improvements I had hoped to.

[hiran]

I tried changing my fork to

Code: Select all

if: github.ref == 'refs/heads/master' || endsWith(github.ref, 'maintenance')

This build https://github.com/mcarans/oolite/actio ... 3132368353 produced a tagged prerelease https://github.com/mcarans/oolite/relea ... 16-334d25a

Will that tagged prerelease work with appimagehub?

I added your repo URL and the CI started testing
https://github.com/mcarans/oolite/relea ... 4.AppImage
But then the logs look difficult to interpret (which line was executed, which was printed?).

I am now getting better at running tests:

• download the appimage we want to test

• download the linter (it is two files):
  - https://raw.githubusercontent.com/AppIm ... xcludelist
  - https://raw.githubusercontent.com/AppIm ... ir-lint.sh

• extract the appimage
  - cd /tmp
  - appimage --appimage-extract

• run the linter on the obtained appdir
  - appdir-lint.sh squashfs-root

With the abovementioned appimage I get this output:

Code: Select all

$ ./appdir-lint.sh squashfs-root
WARNING: No appdata file present. Please provide one in the AppImage as per the instructions on https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
Lint found no fatal issues
$ echo $?
0
$ 

As the linter exits with 0 we could say that it's ok. But no appdata file, no screenshot information. For the catalog they will try to start the app and screenshot it via automation - that is not what we want.

Inside the appimage we need to provide a file named

Code: Select all

/usr/share/metainfo/space.oolite.Oolite.appdata.xml

[hiran]

Actually we could add this linter to our build process - just before the AppImage is getting created. Then we'd have first hand feedback.