-
-
Notifications
You must be signed in to change notification settings - Fork 119
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
Unify release flags and correctly mark dev build releases #1324
Conversation
crates/fj/build.rs
Outdated
@@ -23,8 +23,8 @@ impl Version { | |||
let commit = git_description(); | |||
|
|||
let official_release = | |||
std::env::var("FJ_OFFICIAL_RELEASE").as_deref() == Ok("1"); | |||
println!("cargo:rerun-if-env-changed=FJ_OFFICIAL_RELEASE"); | |||
std::env::var("release-detected").as_deref() == Ok("true"); |
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.
The name can be changed, as for me it is a bit misleading. I propose e.g. is-official-release
.
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.
The release operator doesn't set any environment variables, it sets github actions outputs.
So if you want the build.rs
to have access to the data, you need to export it in the step that will call cargo build
.
At a glance, I'd say say this needs to happen here https://github.com/hannobraun/Fornjot/pull/1324/files#diff-ea3ea8c9932adc7ba8161ceda844fedd43b006848ef1140c050cbd7ea0788a18R65
Environment variables, as a best practice, are always written in all caps. So I would propose to call it RELEASE_DETECTED
then.
On the aforementioned step - the one that runs cargo build
- we could then populate the variable like so:
- name: Some step
env:
RELEASE_DETECTED: needs.calculate-release-flags.outputs.release-detected
# ...
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'm open to renaming this output/variable, although I'm not sure about is-official-release
. There's no such thing as an unofficial release, so what exactly does that mean? (Yes, I realize the previous environment variable did the same thing.) I agree with @hendrikmaus' point about capitalization.
Personally, I'd be fine with RELEASE_DETECTED
, but that's just bikeshedding. I'd merge this pull request with any semi-reasonable naming choice. We can always improve things in follow-up PRs.
defaults: | ||
run: | ||
shell: bash | ||
|
||
jobs: | ||
calculate-release-flags: |
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.
Perfect, this is the way to go.
Minor thing to fix: the job needs to define the output that the release operator populates, see:
https://docs.github.com/en/actions/using-jobs/defining-outputs-for-jobs
Like that, the subsequent jobs can access the data.
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.
Good catch, fixed 👍🏻
.github/workflows/cd.yml
Outdated
@@ -69,6 +88,7 @@ jobs: | |||
|
|||
release: | |||
name: Release | |||
if: ${{ steps.calculate-release-flags.outputs.release-detected == 'true' }} |
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.
if: ${{ steps.calculate-release-flags.outputs.release-detected == 'true' }} | |
if: ${{ needs.calculate-release-flags.outputs.release-detected == 'true' }} |
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.
Fixed, thank you!
crates/fj/build.rs
Outdated
@@ -23,8 +23,8 @@ impl Version { | |||
let commit = git_description(); | |||
|
|||
let official_release = | |||
std::env::var("FJ_OFFICIAL_RELEASE").as_deref() == Ok("1"); | |||
println!("cargo:rerun-if-env-changed=FJ_OFFICIAL_RELEASE"); | |||
std::env::var("release-detected").as_deref() == Ok("true"); |
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.
The release operator doesn't set any environment variables, it sets github actions outputs.
So if you want the build.rs
to have access to the data, you need to export it in the step that will call cargo build
.
At a glance, I'd say say this needs to happen here https://github.com/hannobraun/Fornjot/pull/1324/files#diff-ea3ea8c9932adc7ba8161ceda844fedd43b006848ef1140c050cbd7ea0788a18R65
Environment variables, as a best practice, are always written in all caps. So I would propose to call it RELEASE_DETECTED
then.
On the aforementioned step - the one that runs cargo build
- we could then populate the variable like so:
- name: Some step
env:
RELEASE_DETECTED: needs.calculate-release-flags.outputs.release-detected
# ...
.github/workflows/cd.yml
Outdated
@@ -69,6 +88,7 @@ jobs: | |||
|
|||
release: | |||
name: Release | |||
if: ${{ steps.calculate-release-flags.outputs.release-detected == 'true' }} | |||
needs: binaries |
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.
needs: binaries | |
needs: | |
- binaries | |
- calculate-release-flags |
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 wrote that way because the calculate-release-flags
is an indirect dependency via the binaries
. But it won't work with an if expression above: if: ${{ needs.calculate-release-flags.outputs.release-detected == 'true' }}
, so fixed as well!
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.
Thank you for this pull request, @kopackiw!
This looks good to me (modulo the problem with the output/variable that @hendrikmaus pointed out). Regarding testing, I assume it would be a pain to set up a test outside of this repository, so let's just merge it and see how it goes, once @hendrikmaus runs out of problems to point out 😄
crates/fj/build.rs
Outdated
@@ -23,8 +23,8 @@ impl Version { | |||
let commit = git_description(); | |||
|
|||
let official_release = | |||
std::env::var("FJ_OFFICIAL_RELEASE").as_deref() == Ok("1"); | |||
println!("cargo:rerun-if-env-changed=FJ_OFFICIAL_RELEASE"); | |||
std::env::var("release-detected").as_deref() == Ok("true"); |
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'm open to renaming this output/variable, although I'm not sure about is-official-release
. There's no such thing as an unofficial release, so what exactly does that mean? (Yes, I realize the previous environment variable did the same thing.) I agree with @hendrikmaus' point about capitalization.
Personally, I'd be fine with RELEASE_DETECTED
, but that's just bikeshedding. I'd merge this pull request with any semi-reasonable naming choice. We can always improve things in follow-up PRs.
Thank you both for a detailed review! I've fixed all issues and I think we're ready to go out from a draft to a mergeable PR. I think next step is to test it on production 😄 |
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.
Thank you for the changes, @kopackiw!
As far as I'm concerned, this is good to go, but I'd like to give @hendrikmaus the chance to take another look. I'll merge as soon as he gives the go-ahead!
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.
Thanks @hannobraun, I think we're good to go.
Thanks, @hendrikmaus! Merging. |
Everything seems to work perfectly! Binaries are built, no errors, and |
❗NOT TESTED❗
This PR unifies the
FJ_OFFICIAL_RELEASE
andrelease-detected
flags that carry the same meaning.To properly read the
release-detected
as env, work in #1270 is required I think.Closes #883