chore(ci): handle -rc and -pr. pre-release tags in vdev publish workflow

[thomasqueirozb]

Summary

Follow-up to #25418. vdev_publish.yml now skips crates.io publish and marks GitHub releases as pre-releases for tags containing -rc or -pr. (e.g. vdev-v0.3.4-rc.1, vdev-v0.3.4-pr.1234). Adds a "Testing vdev changes in CI" section to vdev/README.md documenting the RC/PR pre-release workflow. Removes VDEV_VERSION from prepare.sh — CI now installs vdev via --manifest-path vdev/Cargo.toml so vdev/Cargo.toml is the single source of truth.

Vector configuration

NA

How did you test this PR?

End-to-end test of the full pre-release workflow:

1. 63fd4c5: Tagged vdev-v0.3.4-pr.25456 from this branch with an intentional check-markdown failure baked into the vdev binary.
2. vdev_publish.yml run built and uploaded the pre-release binaries to GitHub (no crates.io publish — confirmed publish job was skipped).
3. Fixed the --manifest-path install path in 7ce2689, which resulted in the failing Check Markdown run.

Change Type

• Bug fix
• New feature
• Dependencies
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the `no-changelog` label to this PR.

References

• Related: chore(ci): install vdev via binstall #25418

[pront]

General comment: The PR description should explain the proposed process and include a motivation section.

This makes PR prereleases installable but it doesn't prevent us from merging a 0.3.4-pr.25456 version into origin/master. We will need a pre/after merge policy to cover this aspect.

[pront]

Can we simplify this? I wonder if we need -rc. How does tagging work while iterating on a PR?

See example:

0.3.4-pr.25456.1
0.3.4-pr.25456.2
0.3.4-pr.25456.3

[thomasqueirozb]

-rc not needed, but there's no harm in leaving it here. I think that we should be able to overwrite tags and pre-releases

[pront]

-rc not needed, but there's no harm in leaving it here.

Let's always default to the YAGNI principle. It is fine to add it later if there's a use case.

I think that we should be able to overwrite tags and pre-releases

I’d be a little wary of overwriting tags/releases here. For this flow, the tag is effectively the immutable coordinate CI uses to fetch a vdev binary. If we change a tag, then it is harder to answer which binary a run used. My preference would be to keep prerelease artifacts append-only. We would still need an idea here on what to do Once we want to merge a PR which essentially means promote e.g. 0.3.4-pr.25456.3 to an actual vdev version. Also, need to consider automating cleaning up versions.