fastmail / mint-tag Goto Github PK

Can we drop the Maybe[]? You said it might've been added because of some kind of type system carping. If we can ditch them, all the better. Maybe[] is usually wrong compared to just leaving things unset.

An experiment: we discussed whether we'd benefit from seeing that an MR's sha is already available locally, and so no git fetch is required.

This is fine, but I will restate my original advice, which are you free to discount, and I will not be bothered. :)

I said "be sure to put the version as the very first thing" which might be, say:

v19 tag from tag-minter where blah blah

[[...]]
pie = eaten

…because you'd always be able to parse that no matter what. "Every tag starts with v then a string of digits, then a space." You seem to have put it into the TOML, meaning that for all time, every tag is described in TOML.

Probably this is fine, and I just want to know you decided knowing what I had meant!

If we need a stock prefix (to distinguish from system() output?) let's make it mint-tag or something?

I think that in fact you may want to use the /repos/:owner/:repo/pulls API end point, which has a ?state=open parameter. This returns full pull requests, so the big question is whether you're better off:

1. fetching the list of issues with this label
2. performing N fetches, one per issue with PR

or

1. fetching all open PRs, filtering client-side by label
2. …and possibly performing more than one fetch, because of pagination

Page size can be set to 100, which seems likely to always be more than enough, reducing the query count from 1+N to 1.

Thrown out as an idea for the future, largely: if you have several remote at the same service, you may end up with more distinct TCP connections than required. You should be able to provide them all with a shared-across-the-app LWP::ConnCache to minimize this.

You have made GitLab and Github, but GitHub seems to style themselves GitHub, with a big H.

Maybe this is fiddly, but we should probably match both brands or at least both files. Sincerely, Rik from FastMail.

I think you're probably better off getting a prefix match first, up to and excluding the s.n., then picking the next s.n. available. It'll run git-tag once instead of N times, and have the same number of races. No?

Seems strange to me to let the approver exit, instead of just letting it signal approval. Then the caller can do the right thing. Minor, but we're usually well served to keep things like "exit" near the top level if we can.

Made my first mint-tag config today. I left out meta.committer_name and meta.committer_email because I was just fiddling locally. Later, calamity!

mint-tag | build-mysql-8: octopus merging 5 MRs
mint-tag | build-mysql-8: run: git merge --no-ff --no-commit 3aa343d8076dae8433b43cbf3ae079d8b6a52a3e 52480f1b105f95cf1c484296d19a7f15b50baadc 4acb6a3a8ca1ca3540a99ab0288f08e01c7629dc 29d4460d33e069d6e1535fd109f1d5be52d75514 c0649bd3b34f163fbe8c9b150ac53995b1cc2cf9
mint-tag | build-mysql-8: (git): fatal: empty ident name (for <>) not allowed

This is obviously easily fixed, and I did, but it took a moment to make the connection.

Suggest either saying "you must have these config values", or, taking the local git defaults.

^-- should that be fatal instead?

That is, we will exit immediately, leaving the working directory in a state of disarray. I think that's useful, because maybe you want to go in and see what's up. But we should be loud about doing so (red text), because it's possible you'll be in the middle of a rebase, or in a detached HEAD, or some other weirdness.