Skip to content
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

Distribute snapshot builds of Reposilite #1287

Closed
dzikoysk opened this issue May 8, 2022 · 6 comments
Closed

Distribute snapshot builds of Reposilite #1287

dzikoysk opened this issue May 8, 2022 · 6 comments
Labels
distribution Issue refers to target platform, e.g. Docker

Comments

@dzikoysk
Copy link
Owner

dzikoysk commented May 8, 2022

Request details

.

@dzikoysk dzikoysk added the distribution Issue refers to target platform, e.g. Docker label May 8, 2022
@WithoutAName25
Copy link
Contributor

My idea would be to build SNAPSHOT versions and publish them on https://repo.panda-lang.org/#/snapshots. It should be possible to append -SNAPSHOT to the version in the build.gradle.kts if, for example, the environment variable SNAPSHOT is set to true.
The only problem with this approach is that if the current latest released version is, for example, 3.0.0 the next SNAPSHOT build would have the version 3.0.0-SNAPSHOT but it should be 3.0.1-SNAPSHOT if the next version to be released in the future is 3.0.1.
One solution could be that we increase the version after each release instead of before each release. Another possible solution could be to always use just 3-SNAPSHOT or 3.0-SNAPSHOT or 3.x-SNAPSHOT but I don't think that's how it's meant to be.

@dzikoysk
Copy link
Owner Author

Maybe something like this could be helpful:

🤔

@WithoutAName25
Copy link
Contributor

I have tried the plugin in a test repo and it is basically designed to manage the complete versioning of a project. Do we want to automate the hole versioning stuff or do we only want to publish nightly standalone versions?

The relevant steps that the plugin does:

  • remove -SNAPSHOT from the version
  • commits the new version
  • creates release tag with the current version for that commit
  • increases the last number of the version (1.0.0 -> 1.0.1 or 1.0.0-alpha.1 -> 1.0.0-alpha.2) or set it to a predefined version
  • commits the new version with the -SNAPSHOT flag

The problems with the plugin:

If we want to automate the versioning, I think it is better to update the version with github actions manually. Then we could update the version in all places.
If we only want to publish nighty standalone versions, we need another solution.

@dzikoysk
Copy link
Owner Author

dzikoysk commented May 13, 2022

At first I thought that nightly builds as a standalone JAR could be enough for us, but after a while I think it might be just better option to provide standard snapshot builds. The reason why I think it might be just a good step for a project is that because this time we're also providing API for developers (plugins), so it might be quite useful to provide valid maven artifacts for them in case of any changes in the main codebase.

Would be great if we could somehow automate the release process as much as possible, so I don't have to repeat over and over the same process before each release.

Good research about the gradle-release plugin, good to know it's not really actively maintained and has several issues. Could you take a look at:

The best tool would work like:

$ gradlew release 3.0.2
1. Removes -SNAPSHOT from 3.0.2
2. Builds project
3. Releases 3.0.2
4. Creates commit for 3.0.2 release (we don't really care about tag as I need to do it on my own in GitHub Releases page anyway)
5. Bumps version to 3.0.3-SNAPSHOT
6. Creates commit

@WithoutAName25
Copy link
Contributor

The axion-release-plugin looks like the best choice for us. It is completely based on git tags and has no hard-coded version in the build.gradle.kts. A nice feature is also, that the plugin can update all files automatically where the version has to be updated. The only downside of this plugin is that it's primarily for groovy (allegro/axion-release-plugin#285, allegro/axion-release-plugin#449). That means that we probably need to create some own extension functions to make it easier. Btw you should probably update the title of this issue.

@dzikoysk dzikoysk changed the title Publish nightly versions of standalone jar files Distribute snapshot builds of Reposilite May 16, 2022
@dzikoysk
Copy link
Owner Author

dzikoysk commented May 16, 2022

Ugh... Groovy. It'll be probably quite ugly integration with closureOf, but I think we can try to do that. Maybe it'll work for our use-case that is relatively simple 🤔

dzikoysk pushed a commit that referenced this issue May 20, 2022
* Configure axion-release-plugin

* Configure github actions

* Configure github actions permissions

* Rename workflows
dzikoysk added a commit that referenced this issue Jun 9, 2022
dzikoysk added a commit that referenced this issue Jun 9, 2022
…1375)

* GH-1287 Add BOM to README

* GH-1374 Enforce UTF-8 file encoding for JVM process used by Gradle

* Release 3.0.0-rc.1

* Release 3.0.0-rc.1

* GH-1374 Mark sources as 3.0.0-rc.1
dzikoysk pushed a commit that referenced this issue Jul 8, 2022
* Configure axion-release-plugin

* Configure github actions

* Configure github actions permissions

* Rename workflows
dzikoysk added a commit that referenced this issue Jul 8, 2022
…1375)

* GH-1287 Add BOM to README

* GH-1374 Enforce UTF-8 file encoding for JVM process used by Gradle

* Release 3.0.0-rc.1

* Release 3.0.0-rc.1

* GH-1374 Mark sources as 3.0.0-rc.1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
distribution Issue refers to target platform, e.g. Docker
Projects
None yet
Development

No branches or pull requests

2 participants