-
Notifications
You must be signed in to change notification settings - Fork 323
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
Nightly proccess preparations: Setting Enso version through the environment #3241
Conversation
bacc4db
to
f58054c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update CODEOWNERS - I propose to remove the ownership of CHANGELOG entirely (as proposed in #3247 (review))
// EDIT: after a call we decided, that it is not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, although I'm not sure how the library management will work when the edition got linked to the enso version. I'd like to see @radeusgd review here
val currentEdition = sys.env.getOrElse( | ||
"ENSO_EDITION", | ||
defaultDevEnsoVersion | ||
) // Note [Default Editions] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose, the Default Editions
note should be also updated
project/BuildInfo.scala
Outdated
scalacVersion: String, | ||
graalVersion: String, | ||
currentEdition: String, | ||
stdLibVersion: String | ||
): Seq[File] = { | ||
val gitInfo = getGitInformation(log).getOrElse(fallbackGitInformation) | ||
val isRelease = isReleaseMode | ||
val isInternalDevelopmentBuild: Boolean = | ||
ensoVersion == defaultDevEnsoVersion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we already have isRelease
. Why not specify dev build as an inversion of release, like !isRelease
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want a development build not in the 'internal' mode - for example to test how it behaves with a changed version string, but not in release mode.
If I understand correctly, our usual CI will actually run with isInternalDevelopmentBuild == false
as it will override the version (and so for example the CI artifacts will be not internal-dev but not release either).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This flag was actually used to instrument some badly behaving tests. I figured a different and better way to tackle this, so I think it can actually be removed.
…gine-version-from-env
…sion-from-env # Conflicts: # distribution/lib/Standard/Table/0.0.0-dev/src/Data/Position.enso
(A sbt clean would do, but we can easily make it even easier)
…rs blocked with overlong jobs
Pull Request Description
This PR introduces new version-deciding logic to the Engine. The goal is twofold:
ENSO_VERSION
andENSO_EDITION
environment variables.0.0.0-dev
. It will be used whenENSO_VERSION
is not defined. Typical use case is a local, development build.This 0.0.0 version needed a tweak in our tests to properly work. Many thanks to @radeusgd for all the help!
Also,
CHANGELOG.md
was moved to the repository root.All these changes are needed for nightly builds.
Important Notes
Eventually in the future even those
0.0.0-dev
directories should be gone, but this is a matter for separate task (restructuring the engine layout in the repository). Existing use-cases can likely be covered with some symlink trickery.Checklist
Please include the following checklist in your PR: