feat: add build information to build comment

[m-span]

Adds feat. requested in #3393

example output:

SELECT
  b
FROM
  a

-- Generated by PRQL compiler version:0.11.3-230-ga6218a6f (https://prql-lang.org)

On my M1 pro, it appears to add ~0.5s to the re-build process, bringing the total to somewhere between 3.6 and 5.7 seconds

[m-span]

hmm CI tests are failing in an interesting way:

thread 'main' panicked at prqlc/prqlc/src/lib.rs:124:26:
Invalid prqlc version number: c91cacc: Error("unexpected character 'c' while parsing major version number")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I don't know how git describe --tags is only outputting c91cacc, especially since that hash commit doesn't seem to exist.

Maybe there's something about how the CI is run that I don't understand? Is git available via command line within the CI?

[max-sixty]

Nice!

Interesting re the git issue. I agree the commit doesn't seem to exist. But OTOH it does state here that that does seem to be the commit... https://github.com/PRQL/prql/actions/runs/9395042476/job/25873760775?pr=4546#step:2:56

I think it's probably creating a merge commit to simulate this branch being merged into main. And it's possibly doing a shallow clone so the tags aren't there.

Do you know if we can change the clone to be less shallow?

Either way we should make this robust to not having tags there — e.g. fall back to an empty string, I think.

[max-sixty]

Yes seems like we need something like: actions/checkout#217 (comment)

[max-sixty]

No obligation to use vergen, but:

• when I run this I don't get the version — is there a different check you're running?

cargo run -p prqlc -- --version
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
     Running `target/debug/prqlc --version`
prqlc 0.11.5

• are we sure about the rerun-if-changed approach is correct? I think vergen tries to handle that correctly (but don't know detail)

[eitsupi]

Doesn't this mean that the build will fail if the git command is not available?

[aljazerzen]

Yes, this will be a problem on some build platforms without git or if the build process strips git repo out of source code.

[eitsupi]

I'm not sure how this works with downstream packages. What happens if I install from crates.io?

[max-sixty]

I'm not sure how this works with downstream packages. What happens if I install from crates.io?

It would need to fall back to just the version number

[aljazerzen]

I think this is unnecessary for released versions of prqlc, as version number already describes git tag, which gets us the git rev.

It is useful for development builds. If you also think so, I'd suggest we:

• add git commit hash only if current commit does not have a git tag,
• silently skip this if git is not installed,
• silently skip this if git repo is not found.

[aljazerzen]

Yes, this will be a problem on some build platforms without git or if the build process strips git repo out of source code.

[max-sixty]

No urgency, but just FYI I thought this was cool and would be nice to have!

[max-sixty]

Closed by #4804 (added us both onto changelog @m-span , hope that's reasonable)