Build utiLITI using github actions

weisJ commented 2 years ago

I did a test run of the PR on my fork and it seem to work: https://github.com/weisJ/litiengine/actions/runs/1641284682 Because the produced output it rather large and there is a limit on how much storage action artifacts can take up in total I have decided to not run the action on every push. Instead the normal CI just checks whether jpackage succeeds. Instead the package action has to be triggered manually in the actions tab.

steffen-wilke commented 2 years ago

Looks good so far 👍

One more thing we should probably add is an option to set the input release = true such that the SNAPSHOT suffix disappears for actual release builds.

weisJ commented 2 years ago

I am not quite sure why the previous setup for publishing didn't work out as I am not very experienced with the "raw" maven-publish plugin. I have now modified to use a setup which I know will work as I am using it myself. The following properties will be need to be provided locally (I recommend storing them in <user_home_path>/.gradle/gradle.properties:

ghGitSourceUsername: The github user name. This is gurkenlabs
ghGitSourcePassword: An appropriate github access token. It has to have access to create tags in the repo.
ghNexusUsername: The username for the maven nexus you are publishing to i.e. OSSRH_USERNAME
ghNexusPassword: The password for the maven nexus you are publishing to i.e. OSSRH_PASSWORD

For singing either of two approaches will work:

Either
- signing.keyId: The id of the gpg key
- signing.password: The password of the gpg key
- signing.secretKeyRingFile: Path to the gpg key
Or:
- useInMemoryKey = true
- signing.inMemoryKey: The ascii armored version of the gpg key with \n instead of newlines (i.e. OSSRH_GPG_SECRET_KEY)

Then publishing works like this:

For snapshots:

./gradlew prepareVote -Pgh -Prc=1 -Prelease=false

Expected output:

litiengine v0.5.2-beta-SNAPSHOT-rc1 is ready for preview.

Git SHA: <some sha>
Staging repository: https://oss.sonatype.org/content/repositories/null

For releases
```
./gradlew prepareVote -Pgh -Prc=1 -Prelease=true
```
Expected output is the same as for the snapshot version but instead a proper staging repository url (i.e no null path) and no -SNAPSHOT suffix.

In both cases an appropriate tag in the github repository is created. The -Prc= property sets the version of the release candidate. It's perfectly safe to reuse the same number (I do this for snapshots to not clutter the the repo with tags). It will only affect the tag in the repo. For example in the above case the created tag will be called v0.5.2-beta-rc1.

In the case of releases (-Prelease=true) you still have to manually release it in the nexus repository manager. (I assume this is oss.sonatype.org for you.)

Please check whether this works for you as I can't test it myself :D

weisJ commented 2 years ago

This doesn't yet automatically attach the artifacts from the jpackage action to the release tag as resources. I'll have to read more into how the github api works first :)

nightm4re94 commented 2 years ago

Just so you know, we're waiting out with the release until this feature is ready. Thank you!

weisJ commented 2 years ago

There is now an action to automatically create the github release. It is run if a tag is created that matches v\d+\.\d+\.\d+-rc\d+ (e.g. v10.0.15-rc1), which is precicesly the format that prepareVote creates. Note that the action won't run for snapshot builds. The action I have added previously isn't used for this but I have left it existent so one can easly create a build of utiLITI manually without having to create a tag (the action can be manually run through the actions interface).

Example of how the release looks: https://github.com/weisJ/litiengine/releases/tag/v10.0.15-rc1

Some additional notes about the release process: Instead of manually publishing through the nexus one can also run ./gradlew publishRelease -Pgh -Prc=1, where the value of rc is the same as in prepareVote. I can't vouch for it 100% as I haven't used this command myself (I like to check the jar content in nexus before releasing).

Did you try whether prepareVote works for you as described above? It's safe to run as you can still manually delete the created tag. I'd rather not wan't to debug this on the master branch later :D

nightm4re94 commented 2 years ago

Thank you! Since the relaunch of our website, we have decided no longer to distribute the executables on the GitHub release page, but via our website. Therefore, we don't need the utiLITI packages here.

weisJ commented 2 years ago

In this case if prepareVote is working for you this should be done. I'll just remove the part that uploads the assets to the github release then. If you wan't I can add a link the website instead.

nightm4re94 commented 2 years ago

Please do :) https://litiengine.com/download/ would be preferred.

weisJ commented 2 years ago

Ok dropped the part where packages are uploaded to the release page. Instead now it refers to the website to download utiLITI. I have added another manually dispateched action which builds a release candidate and automatically releases it i.e. it prepares it using prepareVote -Pgh -Prc=1 -Prelease=1 and directly afterwards publishes it using publishRelease -Pgh -Prc=1. To me it sounds like #439 is exactly about that. Correct me if I am wrong here. Other than that if you could verify that the commands from the script work for you locally this PR should be good to go.

steffen-wilke commented 2 years ago

@weisJ Many thanks for taking care of this and also for preparing a bulletproof documentation 👍

Currently testing the implementation on my local machine. Set all the properties in the gradle.properties accordingly and right now when executing a snapshot release, I get the following error:

Pushing tag to Git remote release-origin: https://github.com/de.gurkenlabs/litiengine.git

Build litiengine-sdk FAILURE reason:
    Execution failed for task ':pushRcTag':
        Caused by: org.eclipse.jgit.api.errors.TransportException: https://github.com/de.gurkenlabs/litiengine.git: https://github.com/de.gurkenlabs/litiengine.git/info/refs?service=git-receive-pack not found: Not Found
            at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:147)
            ...

Seems like it's referencing the wrong repository path WRONG: https://github.com/de.gurkenlabs/litiengine instead of RIGHT: https://github.com/gurkenlabs/litiengine/

steffen-wilke commented 2 years ago

Adjusted it with 8d49674

Ah, I noticed one more thing: when publishing to maven we left out the alpha, beta tags in the past. I believe there were some issues with it related to some build systems if I recall correctly. So, we need to adjust the version for the maven release to be "plain".

weisJ commented 2 years ago

In this case simply leaving the beta off the version would do the trick a lot easier than adjusting it during release. For utiLITI the beta has to be stripped anyway for jpackage to work, so there really isn’t any place to observe that the beta part exists in the first place.

steffen-wilke commented 2 years ago

Okay, we're getting there:

I have the artifacts in a staging repository now but validation currently fails:

Invalid POM: /de/gurkenlabs/litiengine/0.5.2/litiengine-0.5.2.pom: Project name missing, Project description missing, Project URL missing, License information missing, SCM URL missing, Developer information missing

Apparently, we're missing some meta information.

litiengine-0.5.1.pom:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.gurkenlabs</groupId>
  <artifactId>litiengine</artifactId>
  <version>0.5.1</version>
  <name>litiengine</name>
  <description>LITIENGINE is a free and open source Java 2D Game Engine. It provides a comprehensive Java library and a dedicated map editor to create tile-based 2D games.</description>
  <url>http://litiengine.com</url>
  <licenses>
    <license>
    <name>MIT License</name>
    <url>https://github.com/gurkenlabs/litiengine/blob/master/LICENSE</url>
    </license>
  </licenses>
  <developers>
  <developer>
    <id>steffen</id>
    <name>Steffen Wilke</name>
    <email>steffen@gurkenlabs.de</email>
    </developer>
    <developer>
    <id>matthias</id>
    <name>Matthias Wilke</name>
    <email>matthias@gurkenlabs.de</email>
    </developer>
  </developers>
  <scm>
    <connection>scm:git:git://github.com/gurkenlabs/litiengine.git</connection>
    <developerConnection>scm:git:git@github.com:gurkenlabs/litiengine.git</developerConnection>
    <url>https://github.com/gurkenlabs/litiengine/</url>
  </scm>
  <dependencies>
  ...
  </dependencies>
</project>

litiengine-0.5.2.pom:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>de.gurkenlabs</groupId>
<artifactId>litiengine</artifactId>
<version>0.5.2</version>
<dependencies>
...
</dependencies>
</project>

weisJ commented 2 years ago

Fixed in #442

gurkenlabs / litiengine

Build utiLITI using github actions #436