Issuing another patch for the version nag
#v0.13.3 - 20th September 2024
fallow tusk
we really, really, really, really need this process to be more automated :/
cc <@&946480760016207902>
fossil bear
@fallow tusk anything we can do to help on the CI module refactoring side?
Since there's a release module, currently only moving around logic that's already there. Good time to take requests
In a perfect world what features would github.com/dagger/dagger/release have, and would it help with this problem?
fallow tusk
at a high level, something like dagger call shipit --commit <sha> --bump patch or --version <version> would be 
including all the SDKs, and helm, and etc. etc. - ideally idempotent or retryable from checkpoints or something
honestly right now the biggest pain point is just all the manual copy-pasting, on top of the fact that the snippets are Bash and so they're not compatible with my shell (Fish) so I have to manually edit each one (last release I tried just running from Bash and it was miserable)
Docs deploy would also need to be automated, ideally
it's gotten a lot better, but still, I want to just click a button and watch a pipeline fan out to everything and go green
fallow tusk
lol @obtuse patrol approved before I could ask - 
https://github.com/dagger/dagger/pull/8523
fallow tusk
we really, really, really, really need this process to be more automated :/
also to be fair I feel like with unlimited time we'd all love to automate this, but it's just-bad-enough to complain about and not-bad-enough to prioritize. i guess i'm just advocating to finally prioritize it
fossil bear
what would --bump do? actual generation of the tag, applying & pushing the tag?
or would the tagging be done manually before?
asking because actually tagging is harder to make idempotent I think
fallow tusk
what would `--bump` do? actual generation of the tag, applying & pushing the tag...
imo: a commit should go in, and all necessary side effect should come out, from the same starting point as RELEASING.md, which is basically just "do you know what commit you want to ship?" - so it should create + push the tag
same for the github releases
fossil bear
at what point does the "next" version get bumped in the changie files?
fallow tusk
asking because actually tagging is harder to make idempotent I think
the Concourse git resource handled this by just looping and making sure the tag is pointing to the same commit, with an optional force: true - will go check
fossil bear
isn't there a non-atomic change with 1) setting next version in a file in the repo 2) tagging the commit?
fallow tusk
ah yep we actually update the changelogs and then tag + push that commit
fossil bear
what happens if I commit a change that sets the version to foo in changie, but then don't tag that commit with the same version?
seems not very DRY
I don't think I will ever like the changie model tbh. feels like an anti-pattern
fallow tusk
it makes automating releases a bit annoying, but the end result is nice at least for users
fossil bear
you mean the nice changelogs?
fallow tusk
yea
fossil bear
that part is nice for sure but i don't think it requires changing being a critical input to versioning & releasing
it should be downstream
anyway
as it is, our release tags are a cache of information in changie files which is the de facto source of truth
fallow tusk
the tagging is pretty inaccurate too - we tag the merge of the PR that updates the changie files, so technically if someone merges before the changie PR, that'll be incorrectly included in the tag (or actually, I guess it'll just become part of the release, but not in the changelog)
i think we could fix that by just tagging the changelog commits on an orphaned branch and merging the tag
not an orphaned branch, just, not on a branch. i forget the right git term
fossil bear
the whole thing feels brittle to me but everyone else seems happy so 🤷🏻♂️
fallow tusk
i think it's something users will be doing anyway, so don't mind making sure we can represent it well at least
[pushed v0.13.3 tag]
fallow tusk
v0.13.3 out now - D4GH PR: https://github.com/dagger/dagger-for-github/pull/149
cc @opaque prawn @plucky sigil 🙏
opaque prawn
v0.13.3 out now - D4GH PR: https://github.com/dagger/dagger-for-github/pull/149
...
done
I'll update the playground now and daggerverse after the Go SDK is out
fallow tusk
go SDK should be out i think - i seen't it on pkg.go.dev
honest mirage
Thanks for handling this one @fallow tusk ❤️
honest mirage
the whole thing feels brittle to me but everyone else seems happy so 🤷🏻♂️
Definitely not happy, but also, changes to this area are miserable to do (because this only runs on releases, having this break during a release is annoying)
Spending time refactoring it would be good to do, but with CI stuff been in flux for the last month or so, and the fact that there always seems to be something more important means it's very easy to push off
fossil bear
Makes sense. I'm hoping refactoring our CI will 1) make it easier to improve this, and 2) give us momentum to try and do it
honest mirage
Once we decide on module architecture and all that, I really want to spend the time to improve releasing, but it's probably not worth doing before that? I'd also like to tackle that one personally if I can, it shouldn't be bundled in with everything else
fossil bear
Once we decide on module architecture and all that, I really want to spend the t...
yeah makes sense
honest mirage
The releasing is kinda one of the main reasons I think it would be good to try merging the big ci changes in pieces? Moving bit by bit gives us more visibility into what works/what doesn't, and means we don't end up with everything broken all at once in a release (just little bits 😂😂😂)