As of this commit to Galapagos
<https://github.com/NetLogo/Galapagos/commit/a95d4f97c3e7a97eca07d3521ef992c159d3a935>
and these pull requests for 'headless'
<https://github.com/NetLogo/NetLogo/pull/526> and for Tortoise
<https://github.com/NetLogo/Tortoise/pull/56>, we now have an
artifact-publishing system in place for Tortoise development. As such,
I'll take a few minutes to explain how it works.
First, this system utilizes the publish-versioned SBT plugin
<https://github.com/NetLogo/publish-versioned-plugin>. There's lots of
stress from certain sources on the team for us to be publishing
well-versioned artifacts in order to facilitate having reproducible
builds, and leveraging SBT to give us such a versioning scheme seems
like the logical way to go about this. The plugin enforces the
following versioning scheme for us:
_If `isSnapshot` is `false` in the project's build, your artifacts will
be published using the build's original value for the `version`
setting. Otherwise, the plugin will call out to Git to determine the
SHA of the current commit and append that to the version number, and
will also append "-dirty" to the version number if the Git repo has
uncommitted changes._
Consequently, we should almost never publish dirty builds, and we should
/absolutely never/ make commits that reply upon "dirty" dependencies.
If an artifact is dirty, it's not well-versioned, so using it runs the
risk of breaking our whole "reproducible builds" thing. It's trivial to
make a proper commit out of your changes; just do that.
Since the publish-versioned plugin has a dynamic way of determining the
version of the artifact, it becomes largely impractical to publish with
SBT's standard `publish` command, since that relies upon `version` by
default, and `version` essentially cannot be seamlessly changed while
SBT is running. As a result, *do not publish artifacts by using
`publish`*. Instead, use the `publish-versioned` task that is provided
by the plugin. This task does what we actually want by performing
`publish` with our dynamically-determined `version` value. I also
discourage the use of `package` (which should no longer be used too
often, anyway), and urge you to, in its place, use the
`package-versioned` task provided by the publish-versioned plugin.
The other major part of the system is BinTray <https://bintray.com/>.
BinTray is the place to which our artifacts are being uploaded. You
should create an account on BinTray and let me know what your username
is, so I can then add you to the NetLogo organization (so you can
publish things). You shouldn't have to touch BinTray much at all after
that.
You might notice that all of these projects that publish to BinTray or
depend on artifacts from BinTray use the SBT BinTray plugin
<https://github.com/softprops/bintray-sbt>. You shouldn't have to deal
with this too much, either, as it operates mostly behind-the-scenes.
When you go to publish for the first time (or if you run
`bintray::changeCredentials` in SBT before first attempting to publish),
you will be asked to enter your BinTray credentials. Enter your usename
and the API key that you get from https://bintray.com/profile/edit (in
the "API Key" section). After that one time of entering your
credentials, its use should be largely transparent to you.
After that, you should be able to `publish-versioned` and depend on
`publish-versioned`ed things at will---no more uploading '.jar' files to
servers and fiddling with their privileges---no more juggling transitive
dependency listings. I hope this leads to a smoother development
workflow for us as we continue to work on the Tortoise series of
dependent projects.
Jason Bertsche
Senior Software Developer - NetLogo
--
You received this message because you are subscribed to the Google Groups
"netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
