Closed IAmJulianAcosta closed 3 years ago
Hi.
Yes, you are correct. -apply
argument takes current commit time and uses it as a build number. If you are going with the -apply
approach, then you are right again, there is no way to keep the actual commit time in sync with commit time that was written in pubspec.yaml
. May I ask you why do you need such behaviour? I can understand that you want to use it to track commit via commit time, but that would never be possible due to this offset.
Whole purpose of commit time as build number was to use it to bump build number seamlessly. Please refer to this blog post for more info.
So this my use case:
I have a pre-commit hook that runs -apply
so the version that is going to be built is stored in the commit, and I can use it as reference. After running, it generates the version.
Later on Jenkins I have to run -apply
again in order to get the latest version (based on the commit), so the version that I'm pushing to the device is not the same that gets stored in the commit.
I think that a simple way to fix this is to offer an option to generate the version code from the past commit, or as a timestamp. So if -apply
is running as a hook as I do, it will be linked to the current commit timestamp.
Later on Jenkins I have to run
-apply
again in order to get the latest version
Can't you simply use -version
or -code
to read the stored version?
-version: Reads current version name
-code: Reads current version code
Hi @davormaricdev, sorry, I couldn't answer on time.
I'm running -apply
on jenkins in order to update pubspec.yaml
and to display the version on the app.
What I think it can be done is to have an option to generate version code from current unix time, instead of latest git commit, that way it doesn't depend on commits, but in the timestamp -apply
is run.
In this case, the version code is generated using a pre-commit hook, gets stored in the repo, and when jenkins builds it, it will be the same as the commit.
Do you think this can be done?
I see that there is one issue with having the commit time as a build number, and is that you can't have the real build number committed in
pubspec.yaml
.As the build number is based on the previous commit time, at the moment someone commits, the commit time is not longer representing the right build number as is going to be always one commit behind.
For example if
-apply
runs before commit, the current version stored inpubspec.yaml
will be the one in the previous commit, not the actual commit, and there is never a way to keep both in sync.