ForgeChangelogGradlePlugin : créer un changelog pour forge via gradle

Superloup10

Tu peux get la version de minecraft comme étant celle indiqué ici.
Ensuite pour la version du mod, c’est le même principe.

SCAREX

@‘Superloup10’:

Tu peux get la version de minecraft comme étant celle indiqué ici.
Ensuite pour la version du mod, c’est le même principe.

Le problème c’est qu’à ce moment là il faut copier tout le repo pour ensuite récupérer cette valeur car elle peut être placée dans un fichier différent

Superloup10

Non, avec ForgeGradle, tu seras toujours obligé de mettre

minecraft {
version = "version_aléatoire" // Version aléatoire peut être lu depuis un fichier externe, mais il sera toujours indiqué dans le build.gradle
}

Donc pour y accéder, tu seras obligé de passer par ```
project.minecraft.version

SCAREX

@‘Superloup10’:

Non, avec ForgeGradle, tu seras toujours obligé de mettre
minecraft {
version = "version_aléatoire" // Version aléatoire peut être lu depuis un fichier externe, mais il sera toujours indiqué dans le build.gradle
}
Donc pour y accéder, tu seras obligé de passer par ```
project.minecraft.version

Oui mais dans tous les cas il faut compiler le projet (pas forcément le build mais le mettre en tant que sous-projet)

SCAREX

J’ai rajouté une fonctionnalité : on peut générer les versions via un repo maven (en revanche le changelog pour chaque version est vide puisqu’il n’est pas disponible sur maven)

Par exemple pour le mod FFMT-libs :

{
"homepage": "http://ci.mcnanotech.fr/job/FFMT-libs/",
"1.9.4": {
"1.6.4.175-mc1.9.4": "",
"1.6.3.174-mc1.9.4": ""
},
"1.9": {
"1.6.3.173-mc1.9": "",
"1.6.3.172-mc1.9": "",
"1.6.3.170-mc1.9": "",
"1.6.3.169-mc1.9": "",
"1.6.3.168-mc1.9": "",
"1.6.3.167-mc1.9": "",
"1.6.3.166-mc1.9": "",
"1.6.3.165-mc1.9": "",
"1.6.3.164-mc1.9": "",
"1.6.3.163-mc1.9": "",
"1.6.3.162-mc1.9": "",
"1.6.3.160-mc1.9": ""
},
"1.8.9": {
"1.6.2.159-mc1.8.9": "",
"1.6.2.158-mc1.8.9": "",
"1.6.2.157-mc1.8.9": "",
"1.6.2.155-mc1.8.9": ""
},
"1.8.8": {
"1.6.2.153-mc1.8.8": "",
"1.6.2.152-mc1.8.8": "",
"1.6.2.150-mc1.8.8": "",
"1.6.2.149-mc1.8.8": ""
},
"1.8": {
"1.6.1.148-mc1.8": "",
"1.6.1.147-mc1.8": "",
"1.6.1.146-mc1.8": "",
"1.6.1.145-mc1.8": "",
"1.6.1.144-mc1.8": ""
}
}

SCAREX

J’ai ajouté la génération des versions via git : en revanche si vous souhaitez avoir le changelog de git pour l’instant vous êtes obligé d’avoir ajouté les tags correspondant aux versions car sinon on peut pas trouver les commits correspondants aux versions (j’ajouterai par la suite un moyen de générer ce changelog via les hash des commits).

En revanche je suis bloqué sur un truc : comment générer les versions recommandées et les dernières (pour accéder à la dernière version j’avais pensé à comparer les versions néanmoins le problème est que ça générera la dernière version uniquement pour la dernière version de minecraft).

Voici le code actuellement généré pour un repo git (ici l’exemple est donné via mon repo SCLib) :

{
"homepage": "http://github.com/SCAREXgaming/SCLib/releases",
"1.7.10": {
"1.7.10-1.0.0": "SCAREX : First commit\nSCAREX : Modified changelog",
"1.7.10-1.0.1": "SCAREX : Added gradle wrapper",
"1.7.10-1.0.3": "SCAREX : still testing\nSCAREX : always testing\nSCAREX : And again\nSCAREX : no comment",
"1.7.10-1.0.4": "SCAREX : …\nSCAREX : ..\nSCAREX : Changed version",
"1.7.10-1.0.5": "SCAREX : Trying to add changelog maker",
"1.7.10-1.1.0": "SCAREX : Added changelog again\nSCAREX : Finally added all the plugins I wanted",
"1.7.10-1.1.1": "SCAREX : Testing things of jitpack.io",
"1.7.10-1.1.2": "SCAREX : Nope",
"1.7.10-1.2.0": "SCAREX : -Added blocks and items lists -Added energy blocks -Added abstract item\nSCAREX : Modified version",
"1.7.10-1.2.1": "SCAREX : Added test files\nSCAREX : Added Mekanism Testing things with jitpack.io\nSCAREX : Testing : added optional parameter when publishing\nSCAREX : Testing with install task\nSCAREX : New test",
"1.7.10-1.2.2": "SCAREX : 1.2.2 : - added some CoFH mods for testing - added some source files - fixed bug : the configurator from Mekanism didn\u0027t work\nSCAREX : Renaming + fixed bug"
}
}

robin4002

Version recommandée je pense qu’il faut jenkins.
De même avec jenkins il serai possible de récupérer le message de commit et l’envoyer dans la version associée.

SCAREX

@‘robin4002’:

Version recommandée je pense qu’il faut jenkins.
De même avec jenkins il serai possible de récupérer le message de commit et l’envoyer dans la version associée.

Je connais pas très bien l’API de Jenkins, si quelqu’un peut m’aider

robin4002

Je ne l’ai jamais utilisé non plus.

SCAREX

Après le problème aussi c’est que y’a pas tout le monde qui a accès à un Jenkins

robin4002

C’est pas difficile à mettre en place.
Tu peux aussi l’installer en local sur windows.

SCAREX

@‘robin4002’:

C’est pas difficile à mettre en place.
Tu peux aussi l’installer en local sur windows.

Oui si c’est juste pour faire ça autant le faire manuellement (dans tous les cas on peut remplir le json manuellement)

robin4002

Je pense qu’un programme qui remplit le changelog automatiquement n’a qu’un intérêt si un CI est en place.

Car bon, si tu build manuellement le mod en général tu ne fais pas un build à chaque commit, donc tu peux aussi remplir le changelog manuellement avec autre chose que le message de commit.

SCAREX

@‘robin4002’:

Je pense qu’un programme qui remplit le changelog automatiquement n’a qu’un intérêt si un CI est en place.

Car bon, si tu build manuellement le mod en général tu ne fais pas un build à chaque commit, donc tu peux aussi remplir le changelog manuellement avec autre chose que le message de commit.

Ce que je veux dire c’est que tu peux toujours créer un script pour faire une partie, personnellement je préfère que ce programme soit totalement compatible avec git (car c’est quelque chose que tout le monde peut avoir) et non avec des choses qui utilisent un serveur.

Je vais voir pour intégrer Jenkins.

En attendant je vais utiliser un comparateur pour trouver toutes les dernières version pour chaque version de minecraft, et ces versions seront aussi automatiquement marquées comme recommandée.

SCAREX

Pour ce qui est de comparer les versions : c’est bon je l’ai ajouté.

Actuellement je suis en train de voir pour l’API Jenkins, malheureusement je bloque à un endroit : le json d’une build ne donne pas un accès direct à la version, il ne donne qu’un accès direct à l’id du build ( https://ci.mcnanotech.fr/job/FFMT-libs/175/api/json ). Je voudrai donc savoir si vous auriez un moyen de récupérer cette version facilement ?

robin4002

Le lire dans le fichier build.gradle ?

Je vais voir si je peux faire un script bash pour faire le changelog, ça sera surement plus simple qu’un plugin gradle.

SCAREX

@‘robin4002’:

Le lire dans le fichier build.gradle ?

Je vais voir si je peux faire un script bash pour faire le changelog, ça sera surement plus simple qu’un plugin gradle.

Comme je l’ai dit le problème c’est qui faut importer tout le repo pour avoir la version ce qui compliqué beaucoup, sinon je pensais récupérer le nom de l’artifact et le passer dans le pattern de version

robin4002

Le fichier build.gradle se trouve dans le dossier de workspace de jenkins.
Donc je ne vois pas en quoi c’est un problème.

SCAREX

@‘robin4002’:

Le fichier build.gradle se trouve dans le dossier de workspace de jenkins.
Donc je ne vois pas en quoi c’est un problème.

C’est un problème si la variable est modifiée depuis un autre fichier. Par exemple dans mes mods je change la version depuis le gradle.properties

robin4002

Ah oui en effet