-
Notifications
You must be signed in to change notification settings - Fork 618
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish nightly snapshots #769
Comments
Hi @Arthurm1 , I thought about this myself some time ago... |
@chrjohn Sadly I don't use Maven or github for publishing. I'm struggling to work out how you're currently using github for publishing or do you run the process locally/manually. |
There is a scheduled run every morning. quickfixj/.github/workflows/maven.yml Line 8 in d7c9fe5
For releases we use Sonatype which also have a snapshot repo. |
Wouldn't it be better to have additional workflow for that? There seem to be a solution suggested here https://github.com/orgs/community/discussions/27128 It seems to trigger only when there was an actual commit in the last 24h, which might be desired not to publish unchanged artifacts, but also a possible problem when a nightly build fails due to a flaky test (there would have to be a new commit to master branch so the next day build pick it up). |
@the-thing sounds reasonable. Thanks for checking. 👍 |
Thought a little more about this. Probably the easiest would be if we just upload a snapshot each day regardless of whether there was a change in the last 24 hours or not. |
Reading further on this topic it seems that SNAPSHOT version are not allowed anymore on Sonatype/Maven Central. So probably will either do a nightly release each day (which would be shown here https://github.com/quickfix-j/quickfixj/releases ) or to upload to Github Packages. Any thoughts @Arthurm1 @the-thing ? Thanks |
This sounds good to me. I would release the nightly build to GitHub Maven repository and keep current release unchanged and possibly remove this zip release file. |
It would be great to have this. Especially since MINA in the latest released version of quickfixj does not support TLS 1.3. |
Any help moving this forward (upload to github packages that is) is greatly appreciated. Currently stuck in other projects and vacation. ;) |
@chrjohn it looks like you are right about the Maven Central and SNAPSHOTS, this inconvenient. I think it might be possible to work around that by overriding release version in the pom using :
maven build helper plugin can parse the existing version Current branch name can be retrieved in github actions
It looks possible to get build number as well Perhaps for branches that are NOT 'main|master' a release could be made with a contrived version name like This can be done without committing amended poms, they can stay within the GitFlow scheme. This workaround is fairly horrible and would require house keeping but perhaps it can be considered as workaround. They do not seem to be in a hurry to implement snapshot support. PS snapshots without qualification are not very useful for a project with multiple active branches like QFJ anyway as any snapshot build overwrites predecessors. One needs the build number because : https://central.sonatype.org/faq/can-i-change-a-component/ Probably everything I wrote is a waste of time and one just has to work with snapshots locally and builds for things that are in progress with fail until releases are made. To verify a PR for a project with SNAPSHOT dependencies probably means checking it out and building it locally. :-( |
Is your feature request related to a problem? Please describe.
QuickFixJ isn't released that often but there are often new commits that may have already fixed any issue I might currently have.
I'm experiencing the same as this stackoverflow issue and I'd like to test unreleased versions of QuickFixJ to see if they fix my problem.
Describe the solution you'd like
I'd like to see snapshots posted to a public repo whenever a new PR has been merged. That means I can easily test to see if my issue has been fixed.
Describe alternatives you've considered
I could build from source but that does involve a number of steps. It also doesn't allow me to easily switch between a number of snapshots to check which fixes my issue.
Another option would be more frequent proper releases of QuickFixJ but I imagine that's a lot of overhead for you to support.
The text was updated successfully, but these errors were encountered: