fedora-copr
git_dir_version counts commits backwards (with step -2)
I started to get the weird problems with dnf. It seems the reason is that git_dir_version macro on COPR produces the wrong commit count. Example: https://copr.fedorainfracloud.org/coprs/stsp/dosemu2/build/7216460/ Submitted: 2024-03-26 Version: 0.0.git.643.e4600330-1 https://copr.fedorainfracloud.org/coprs/stsp/dosemu2/build/7205182/ Submitted: 2024-03-23 Version: 0.0.git.647.559e68ea-1
So on 23 mar we had 647 commits, and
on 26 mar - 643 commits...
In fact, the number seems to always be
decremented by 2 instead of being
incremented by 1.
When I do rpkg local locally, I get the
entirely different (and correct) numbers,
so the problem is specific to COPR somehow.
I checked other packages.
They seem to increment, but the numbers
do not match with what I get locally by an
order of magnitude. But at least they increment...
Why on that particular package they decrement,
is what I don't know.
Please help. :)
@clime do you want to comment?
Note that we plan to switch the default SCM method https://github.com/fedora-copr/copr/issues/2820 and retire it.
I switched to tito and still get those
suspicious numbers on copr:
https://copr.fedorainfracloud.org/coprs/stsp/dosemu2/build/7270032/
2.0pre9-1.git.637.6169ffd
while locally it gives 2.0pre9-1.git.11500.6169ffd.
So far I don't see them decrementing,
but I suspect this won't stay for too long.
There is definitely a problem somewhere.
Ah, I see .... there are no git tags upstream, so Tito (and likely rpkg, too?) calculates the default commit-number since the first git commit. For shallow clones (Copr default, --depth 500), the number of available commits becomes much smaller.
You mean like... no tags at all? https://github.com/dosemu2/dosemu2/tags Seems like quite a lot of them actually?
Also the number that copr and tito gives, is above 500 by more than a hundred. So... Do you mean the one needs to add a tag per every 500 commits, or the number will became ureliable?
I mean there are certain tag types that tito (rpkg too, I think) understands.
For Tito, it is in a name-version-release format (try to experiment with tito tag).
Then, Tito calculates the pre-release (--test) commits since the last package's tag.
Also the number that copr and tito gives, is above 500 by more than a hundred.
Hm, I'm not sure about the details, honestly. But it clearly relates to the shallow clone..
the number will became unreliable?
Yes, but I don't think it matters. Without having the right tag within the last 500 commits, the number will be "nonsense" anyway :-/ not good, but that's what we have.
I'd suggest provideing a well-formated tag from time to time in your project (at most 500 commits), or trying to submit some RFE (or PR!) against Tito so we can get a better behavior (tito is configurable, so there could be some opt-in?).
So what should the tito mod do? I guess the launchpad's way of doing that is very good: you can manually specify the version string format. So instead of the commit count (which on LP doesn't even exist, I believe, as I think it does the shallow clone of depth 1), there would be some other number like the build date, right? You definitely want to omit the commit count in "tito --test" mode I believe, and use the build date instead, right?
I'm not sure. Seems like you can not commit custom tags, right?
Can you start the discussion @ Tito issue tracker? There well might be a way around this already, but this is not the best place to ask this. Tito is very configurable, too (there might be a way to override the version using a custom Python code that I don't know).
I can of course commit the tags.
And if nothing else can be done,
will do. But I am sure copr is used
not only by myself. Right now by
relying on a tags with tito --test
you are asing for troubles (while
of course in non-test mode that
might be fine). So I'd like to make
sure I can present this as a generic
copr problem to the tito tracker,
rather than my own problem.
Another possibility is to run
git fetch --unshallow if the tag
is missing. Is it not an option?
It can also be done in a build
script, but I guess it would be
a bit on an abuse for the copr
resources?
Most of the Tito users do the proper tagging. You might be one of the first users facing this - enabling Tito builds in an old-enough project, considering this could be related to https://github.com/rpm-software-management/tito/issues/472 - at least partly. Would Tito before fixing that issue work for you?
Using dates (if tito detects a shallow clone) seems like a good idea to me for tito --test.
Doing deep clones is anti-ECO behavior, and having an option doesn't seem to be worth the effort. We probably wouldn't refuse such a PR, but still...
Would Tito before fixing that issue work for you?
Who will then test your fix? But no problems, will do the tag and see the results.
Doing deep clones is anti-ECO behavior, and having an option doesn't seem to be worth the effort.
Indeed, and if you stop relying on commit number (which you only do for --test I suppose), then you can probably even use shallow depth 1.
What really bothers me in this tag-based solution, is a "magic" number 500. How would I know that the tag should be added per every 500 commits? Are you planning to document that, or is it a temporary w/a for me only?
Who will then test your fix?
I'm not sure I got the question. The issue has been fixed, Tito started to work without the .tito config in git root (recently). That's IMO the reason why I think you are (one of) the first user(s) experiencing this shallow-clone-yet-no-tito-tag problem.
How would I know that the tag should be added per every 500 commits?
You are raising good questions, thank you for that. But we should move to Tito. This seems like a clear Tito topic (aka how Tito works in shallow clones). My personal bet is that the --test option isn't supposed to provide 100% reliable outputs, but still... worth discussing there.
Are you planning to document that, or is it a temporary w/a for me only?
Maybe? Do you want to help with PR.
The issue has been fixed, Tito started to work without the .tito config in git root (recently).
How does this help? Working without .tito doesn't mean no reliance on tags, or does it? I myself do have tito config committed, I can remove it if needed, but will that change anything?
Maybe? Do you want to help with PR.
I think that using dates would be a more promising solution, so no, I don't like to be involved in documenting shallow clone-specific tricks.
In a mean time, tito is exceptionally annoying.
I tried a tito tag and it added a tag
dosemu2-4.0pre9-1 - where it got 4.0?
No idea. It had to add a tag name to a
git log, so when I edit the log before saving
(which is what tito gives me), I could manually
change the number, and then it would generate
a tag based on that. It seems it doesn't support
getting the tag from log, so I have to use
--use-version= and alike options to set what
I need.
But the bigger problem is when I do
tito tag -u I get:
Undoing tag: dosemu2-4.0pre9-1
Checking for tag [dosemu2-4.0pre9-1] in git repo [https:// <my full github login and secret credentials phrase printed>]
ERROR: Cannot undo a tag when the current git state is not clean!
$ git diff
$ (directory is actually clean!)
So:
- the sceme to specify the tag name, is inconvenient
- undoing the tag for some reason goes to remote! Should be done locally.
- undoing tag prints your secret guthub credentials (from git config) on terminal
- undoing tag doesn't work and fails with wrong "git state not clean".
Also it should disallow tagging if the current commit already has a tito tag, but it doesn't check anything.
Now I pushed the tag with
git push --follow-tags and it triggered
2 builds on copr, of the completely
identical version. One was probably
triggered by commit, and another one
by tag. copr should somehow filter out
the duplicate builds.
Now I realized this isn't going to work
because the last version was 2.0pre9-1.git.638.a4acf10
and now I pushed 2.0pre9-1.git.0.358667b,
which is lower. So I asked tito to create the
tag again, hoping it will increment -1 to -2.
But no, it doesn't! It crashes with a python
stack trace instead, so I need to do
--use-release=2. But if it can't even automatically
increment the release number, then I don't
know what it can do...
Anyway, since this is a one-time work-around for me, I just pushed the new tags, and I think the problem is for now "solved". I only need to monitor the commit count to not reach 500. But there is definitely a work to do, before this can be suggested to everyone.