JOLT Community
Replies: 19 comments 19 replies
|
I am quite interested in this; maybe I can help, I published a few lbraries/tools in the past; we may want to use this fork on our project |
|
@riccardocossu sure, feel free to contribute :) before that, we'll have to decide on the new packaging name (see discussion going on in https://github.com/orgs/jolt-community/discussions/4) |
|
A follow up on this:
|
|
so, can we start this task? |
|
Yes, I think we can. I can do the part about the renaming of the jars and bumping the version number. Someone volunteers for the publication of the jars on Maven repository? |
|
We can create 
|
|
But when i try to create namespace 
Hi @bobeal , it seems we can't use this namespace. |
|
@emmansun the main point is that we will have to create an account on maven central; maybe in the name of one of us, but I don't know if it's a good idea going forward. Also we will need to manage who's gonna hold the signing keys (signing of the artifacts is mandatory on maven central) |
|
@riccardocossu yes, we need an account who is the owner of this repository. |
|
@emmansun you were already admin of this repository (the highest role). You are also now owner of the organisation. |
I can only register namespace 
|
|
If it is only about changing the group id (and not all the package names), that's fine for me. |
|
If you change the Of course, keep current package name |
|
We have mainly 2 code branches now: develop and master, what's a light weight release/publish process for us?
Steps 2,3 maybe in same workflow, below workflow was generated by AI. name: Release and Publish to Maven Central
on:
release:
types:
- created
jobs:
release:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Set up JDK
uses: actions/setup-java@v3
with:
java-version: '17'
distribution: 'temurin'
server-id: maven
settings-path: ${{ github.workspace }}
- name: Import GPG key
run: |
echo "${{ secrets.GPG_PRIVATE_KEY }}" | gpg --import
gpg --list-keys
env:
GPG_PRIVATE_KEY: ${{ secrets.GPG_PRIVATE_KEY }}
GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}
- name: Configure Maven settings
run: |
echo "<settings>
<servers>
<server>
<id>maven</id>
<username>${{ secrets.MAVEN_USERNAME }}</username>
<password>${{ secrets.MAVEN_PASSWORD }}</password>
</server>
</servers>
<profiles>
<profile>
<id>gpg</id>
<properties>
<gpg.executable>gpg</gpg.executable>
<gpg.passphrase>${{ secrets.GPG_PASSPHRASE }}</gpg.passphrase>
</properties>
</profile>
</profiles>
</settings>" > ${{ github.workspace }}/settings.xml
- name: Build and deploy all modules
run: mvn clean deploy -DskipTests -P gpg --settings ${{ github.workspace }}/settings.xml
- name: Upload Release Assets
uses: actions/upload-release-asset@v1
with:
upload_url: ${{ github.event.release.upload_url }}
asset_path: |
jolt-core/target/*.jar
json-utils/target/*.jar
cli/target/*.jar
guice/target/*.jar
complete/target/*.jar
asset_name: jolt-${{ github.event.release.tag_name }}-${{ github.job }}.jar
asset_content_type: application/java-archiveOf course, there will be update and also related pom.xml update. @bobeal @riccardocossu , pls review and advise it. |
|
About asset name, isn't it jolt-${{ github.job }}-${{ github.event.release.tag_name }}.jar instead? There is also a Otherwise, LGTM. |
for the signing key, due to we will upload the private key and password to github security env. so i think it's not an issue, anyone of the project/repo owners can check it. I will use below user id to generate signing key:
any concern? |
|
|
@emmansun I never did it with github action (I used to do it back in the days on my local machine), but the reciper sounds good; it has the required steps, but we will also need the maven gpg plugin: https://maven.apache.org/plugins/maven-gpg-plugin/sign-and-deploy-file-mojo.html others than that we may wanna add gpg commits signing like described here, that can be configured on the developer machines, but it should also be done for the commits of the files that may be created during deploy preparation (for example if we use the maven release plugin): |
|
Yes, this workflow requires Maven plugins to work correctly. Specifically:
Here is an example configuration for the <build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>3.0.0</version>
</plugin>
</plugins>
</build>Ensure these plugins are properly configured in your Let's align release/deploy process first. Maybe we also need a special version for test. |
Updated Release Processes:
below is the part of workflow generated by AI, which is used to handle version update and release tag update: - name: Set version
run: mvn versions:set -DnewVersion=${{ github.event.release.tag_name }}
- name: Commit version change
run: |
git config user.name "GitHub Actions"
git config user.email "actions@github.com"
git add **/pom.xml
git commit -m "Update version to ${{ github.event.release.tag_name }}"
git push
- name: Delete existing tag
run: |
git tag -d ${{ github.event.release.tag_name }}
git push origin :refs/tags/${{ github.event.release.tag_name }}
- name: Create and push updated tag
run: |
git tag ${{ github.event.release.tag_name }}
git push origin ${{ github.event.release.tag_name }}The To remove the - name: Set version
run: |
VERSION=${{ github.event.release.tag_name }}
CLEAN_VERSION=${VERSION#v}
mvn versions:set -DnewVersion=$CLEAN_VERSIONExplanation:
Steps 2 : name: Pre-Release Sync
on:
workflow_dispatch: # Manual trigger
jobs:
sync-branches:
runs-on: ubuntu-latest
steps:
- name: Checkout develop branch
uses: actions/checkout@v3
with:
ref: develop
- name: Configure Git
run: |
git config user.name "GitHub Actions"
git config user.email "actions@github.com"
- name: Merge develop into master
run: |
git fetch origin master
git checkout master
git merge develop --no-ff
git push origin masterStep 5: name: Post-Release Sync
on:
workflow_dispatch: # Manual trigger
jobs:
sync-branches:
runs-on: ubuntu-latest
steps:
- name: Checkout master branch
uses: actions/checkout@v3
with:
ref: master
- name: Configure Git
run: |
git config user.name "GitHub Actions"
git config user.email "actions@github.com"
- name: Merge master into develop
run: |
git fetch origin develop
git checkout develop
git merge master --no-ff
git push origin developWe can publish one beta release for test. @bobeal @riccardocossu Any suggestion or concern? I have no experience either. Take Opentelemetry Java project as sample, it typically follows a structured release and branching strategy to ensure stability and maintainability. Here are the details: Branching Strategy:
Release Strategy:
This strategy ensures a clear separation of development, stabilization, and release processes while maintaining high-quality standards. |
|
I fully agree with most of the points here. Only a few comments:
|
yes, for release branch, it's the practice for most of big projects. |
|
updated the branch master to main. |
|
https://github.com/jolt-community/jolt-community/actions/runs/16558541943/job/46823799003 The
To use the
It seems both |
Simplify the release workflows as below:
BTW, it seems the |
|
Publish failed: |
|
Hi All, Start to sync code from |
|
It seems we can't use the release drafter on main 
|
|
Hi @bobeal , Let's limit the release drafter to name: Release Drafter
on:
push:
# branches to consider in the event; optional, defaults to all
branches:
- develop |
|
release drafter has been added late and it seems it is a bit lost. should be better for the next releases. I will rewrite the release notes later by looking at the history of the commits. You can leave them empty for now (if it is not blocking) Not sure limiting release drafter to |
|
I updated the release notes (https://github.com/jolt-community/jolt-community/releases/tag/v1.0.0). And thanks a lot @emmansun for all the hard work to publish the artefacts! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Support to publish this community version to maven repository.
Reference:
Publish your artifact to the Maven Central Repository using GitHub Actions
All reactions