Open dhirschfeld opened 1 week ago
That's nice! Maybe we should modify rattler-build to read the environment variable first :)
That's nice! Maybe we should modify rattler-build to read the environment variable first :)
How does rattler-build
do it? If it doesn't use the date of the tag for a release it would be good to be able to override that by specifically setting the SOURCE_DATE_EPOCH
env var.
For more context, normal builds are triggered by either the pull_request
or push
(to main
) events whereas releases are triggered by the publishing of a GitHub Release (release/published
event) which itself was created by the pushing of an (annotated) tag.
So, releases are always associated with an annotated tag and I use git show -s
in the CI to show either the commit or the tag information.
e.g.
name: build/wheel
run-name: ${{
format(
'[{0}] build/wheel',
(github.event_name == 'pull_request' && format('pr/{0}', github.event.number)) ||
(github.event_name == 'push' && github.ref_name) ||
(github.event_name == 'release' && github.event.release.tag_name) ||
github.event_name
)
}}
on:
# https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#push
push:
branches:
- main
# https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request
pull_request:
branches:
- main
# https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release
release:
types: [published]
Just thought I'd share the snippit I use to get the
SOURCE_DATE_EPOCH
in GitHub Actions:If the build is due to a commit on a PR or a push to
main
then the timestamp of the git commit is used. If the build was triggered by a GitHub Release being published then I use the timestamp of the (annotated) tag rather than the commit.