#go version mismatch
1 messages · Page 1 of 1 (latest)
digging some more, it seems that the engine version is 0.11.9. But why? I copy pasted the CI config from the docs
Ah. The docs say @v5 but that defaults to engine version 0.11
cc @ornate jackal @frozen fog @sour kayak this is a problem
Got it. We need to update docs to v6 and ensure that is updated with every release.
@burnt sun
@dim badger
What would be the signal to update this version number in the config? I'm not sure but it looks like it's a separate version number not tied to Dagger releases
Also the version in the CI config says "latest". Why would the action use 0.11 instead of the one tagged latest?
Every Dagger release, we release a new version of the GitHub Action. When it's a breaking release, we increment the major version of the action.
That's my fault. I assumed "latest" was the default and being lazy I wanted to avoid copy-pasting one more line in 5 different workflow files. So I removed the version line
I do think "latest" should be the default, especially in the current context of rapid change, and the collective push to keep engine and modules up to date
Ok, so if you added that line back, would the latest engine then work with v5 of the action?
Possibly
I don't have the bandwidth to check right now, but depending on what the v5->v6 change involves, it might be the case yes
I'll update the doc. I'm only wondering about users who have existing CI configs. I'm guessing they're not going to automatically or regularly update the action version. So if the version of the action they're using is incompatible with the latest engine, their workflow could break unexpectedly?
Yes. But in practice the action is very simple, it would only break if the dagger CLI syntax breaks
The alternative is that we "fuse" versioning of the action with engine release. So action version 0.12.4 runs CLI version 0.12.4 and that's it. To upgrade the CLI you need to upgrade the Action
That sounds better to me, more consistent if we're anyway releasing a new version of the action with each release, and probably also would eliminate the issue you just faced? But I'm not an expert so will defer to you and others in our team who can comment on downsides of this approach.
versioning is a tricky topic for us in general 🙂 But I tend to agree
I think @ornate jackal likes this option also?
Yes, I also think that this is the best option. Using a single version for all artefacts that we produce strengthens the "one artefact" idea which is simple & sticky.
What are the implications @frozen fog of resetting the versions for the Dagger GitHub Action?