Comments (14)
The Akka team used rsync to publish documentation assets to a Lightbend maintained server (gustav
). Java snapshots were published to maven repositories, originally a bintray repo, and then the actual sonatype snapshots repo when bintray went away. I briefly considered repurposing the Publish
and sbt-publish-rsync
infra, but when I found Apache Arrow's nightlies implementation with a GitHub Action I opted to use it because the precedent was already established by another Apache project and I liked that it was setup to automatically truncate the number of snapshots kept on nightlies.
One of the issues with Akka's current snapshot publishing is that snapshots are available indefinitely until they're deleted manually or until the sonatype infra team decides to do some cleanup, Arrow's solution to keep the last 30 versions seemed like a nice solution. To achieve the same thing using sbt-publish-rsync
would require some customization either in the form of a shell script sbt commands (i.e. steps in an sbt-release
setup), or customization of sbt-publish-rsync
. I think that given publishing snapshots to nightlies is realistically only going to be done by the Pekko project there's not a lot of value in making the process portable.
I think we should drop the existing rsync functionality found in the project infra since it no longer serves a purpose.
from incubator-pekko.
Thanks, after thinking about this I agree with your conclusion to just remove sbt-publish-rsync. There may be a use for it later down the track (if I can figure out the 30 day expiry) but for now its far simpler to just leave your solution.
There is also the fact that implementing this in sbt also requires a workaround due to the fact that sbt only currently allows to publish to one repo, so you would have to do something like https://stackoverflow.com/a/21032721
from incubator-pekko.
I like the current pekko nightly solution. One minor quibble is that the version numbers for Scala 2.12 jars differ from the 2.13 jars. Likewise, for Scala 3 jars.
from incubator-pekko.
I like the current pekko nightly solution. One minor quibble is that the version numbers for Scala 2.12 jars differ from the 2.13 jars. Likewise, for Scala 3 jars.
Are you talking about the artifact prefixes? If so this is intentional, its how Scala deals with binary compatibility
from incubator-pekko.
The most recent Scala 2.13 jars are 0.0.0+26529-29e5cf4b+20230116-1205-SNAPSHOT
https://nightlies.apache.org/pekko/snapshots/org/apache/pekko/pekko-actor_2.13/
The most recent Scala 2.12 jars are 0.0.0+26529-29e5cf4b-SNAPSHOT
https://nightlies.apache.org/pekko/snapshots/org/apache/pekko/pekko-actor_2.12/
The most recent Scala 3 jars are 0.0.0+26529-29e5cf4b+20230116-1213-SNAPSHOT
https://nightlies.apache.org/pekko/snapshots/org/apache/pekko/pekko-actor_3/
from incubator-pekko.
Ah I see what you mean now, its the version numbers being off (i.e. different) for the same single run of publish. We should probably make an issue for this because its going to create confusion for end users.
from incubator-pekko.
The only difference is the timestamp component of the version. I think it's because the publish command is a cross-build task +publishM2
and I guess the timestamp is derived for each version of Scala. We could customize the version format to drop that component if we want them to be consistent, but I think the timestamp is useful when you're experimenting locally and you don't have local commits yet to differentiate versions.
from incubator-pekko.
The principled solution would be the ability to parameterize the timestamp as an input in the publish command so you only generate the timestamp once (i.e. when just before publish
is executed) and then feed it into the publish command so the timestamp is consistent across versions.
I don't know if this is possible in sbt especially with the usage of +<command>
for cross publishing.
but I think the timestamp is useful when you're experimenting locally and you don't have local commits yet to differentiate versions.
There is truth to this but I would assume that if you are publishing locally you would use publishLocal
and at least personally for me I don't care about the timestamp as I am only interested in using the latest version as its an iterative developer flow with quick turnaround
from incubator-pekko.
I found a stack overflow answer that has a recipe for pushing the timestamp to the filesystem and reading it across builds. https://stackoverflow.com/questions/21053785/setting-unique-snapshot-version-when-cross-building-in-sbt
from incubator-pekko.
I found a stack overflow answer that has a recipe for pushing the timestamp to the filesystem and reading it across builds. https://stackoverflow.com/questions/21053785/setting-unique-snapshot-version-when-cross-building-in-sbt
Not the nicest solution but it works and is a nice improvement, ill make an issue for it
from incubator-pekko.
There is truth to this but I would assume that if you are publishing locally you would use publishLocal and at least personally for me I don't care about the timestamp as I am only interested in using the latest version as its an iterative developer flow with quick turnaround
Yes, it's extremely anecdotal but it is something I've done before!
I think in general the timestamp is nice to have for reference sake, at least the date component is.
from incubator-pekko.
Usually, the timestamp is only added when the workspace is not clean, so we need to figure out why that's the case. Otherwise, using the git describe
output (as usual) should give enough details to order snapshot releases and associate them with the corresponding commit.
from incubator-pekko.
@jrudolph I think this is the wrong place for your comment, I think this discussion is of relevance #105 (comment)
from incubator-pekko.
are we in a position to close this?
from incubator-pekko.
Related Issues (20)
- license: acknowledge use of netty code HOT 1
- license: acknowledge use of codahale code HOT 5
- other source files to add licenses to HOT 4
- Drop the shaded protobuf? HOT 1
- use standard pekko notice in jars (except when additions needed) HOT 1
- migrate incubator-pekko-samples to use pekko snapshots HOT 6
- rewrite pekko-platform-guide to use pekko artifacts and to remove Akka refs HOT 3
- remove or replace algolia and google analytics properties HOT 1
- update signature and fiddle properties in project/Paradox.scala HOT 1
- correct values for project-info.conf jdk-versions HOT 1
- current value for project-info.conf release notes link
- Introduce a timer source api? HOT 6
- Remove explicit handling of `java8Home` entirely in Pekko sbt build HOT 3
- See if `scripts/link-validator.conf` can accept wildcards to remove needing to specify Scala minor versions
- Make BroadcastHub only start pulling after atleast one Consumer attached to it?
- Investigate removal of bespoke JDK 1.8 `rt.jar` handling
- Investigate fixing exhaustive match issues in Pekko codebase HOT 5
- Move akka.japi. to java.util.function. HOT 2
- FAILED: HandshakeRetrySpec HOT 1
- Update the deprecate messages HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from incubator-pekko.