[burner]

graphql query works mostly

bearer not working anymore

[dlang-bot]

Thanks for your pull request, @burner!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + tools#466"

[ibuclaw]

Let me know when it's no longer a draft.

[burner]

@ibuclaw I've taken another look, and I think there is nothing more to do until it fails in prod

[ibuclaw]

FYI, you could perhaps test this with something like:

rdmd -version=Contributors_Lib changed v2.109.1..upstream/stable \
    --version=2.110.0 --date='Feb 01, 2025' --output=../dlang.org/changelog/2.110.0_pre.dd

Which is what's ran to generate the dlang.org changelog.

[burner]

@ibuclaw it should ignore PR's now

[ibuclaw]

This is sort of better now, thinking this through, my only remaining gripe is that getGithubIssuesRest doesn't distinguish between issues closed against stable vs master?

As it stands, it looks like bugs fixed in master-only get wrongly attributed to the current release, when they should be in the next (when master->stable is merged again).

Unfortunately this likely means the approach done here is probably wrong, and needs a complete do over. i.e: just scan for Fix #NNNNN in the commit title like bugzilla?

[ibuclaw]

Here. It looks like these are indeed collected, but then ignored.

[ibuclaw]

This is sort of better now, thinking this through, my only remaining gripe is that getGithubIssuesRest doesn't distinguish between issues closed against stable vs master?

$(BUGSTITLE_GITHUB DMD Compiler bug fixes,

$(LI $(GITHUB 17118): GC not collecting under Windows)
...
$(LI $(GITHUB 20929): #line directives mess up -verrors=context)
)
...
Macros:
    VER=2.110.0

1. GC not collecting under Windows dmd#17118 is just a closed issue, (there's no commit to say it was fixed in this release).
2. #line directives mess up -verrors=context dmd#20929 was closed by PR 20930, which went to master, so not part of 2.110.

[ibuclaw]

This now emits.

$(BUGSTITLE_GITHUB DMD Compiler bug fixes,

$(LI $(DMDGITHUB 18281): ICE on attempt to compare deref of two functions ptr)
$(LI $(DMDGITHUB 20859): ICE: class with __vtbl field name causes segfault in Scope::inCfile)
$(LI $(DMDGITHUB 20894): pragma$(LPAREN)msg$(RPAREN) interprets printf format specifiers)
$(LI $(DMDGITHUB 20907): DMD segfaults with static array length parameter derived from left-shifted template parameter property)
)
$(BUGSTITLE_GITHUB Phobos bug fixes,

$(LI $(PHOBOSGITHUB 10574): std.process execve depends on environ pointer not changing)
)

Now needs macros defined in changelog/changelog.ddoc to be useful.

[burner]

This now emits.

$(BUGSTITLE_GITHUB DMD Compiler bug fixes,

$(LI $(DMDGITHUB 18281): ICE on attempt to compare deref of two functions ptr)
$(LI $(DMDGITHUB 20859): ICE: class with __vtbl field name causes segfault in Scope::inCfile)
$(LI $(DMDGITHUB 20894): pragma$(LPAREN)msg$(RPAREN) interprets printf format specifiers)
$(LI $(DMDGITHUB 20907): DMD segfaults with static array length parameter derived from left-shifted template parameter property)
)
$(BUGSTITLE_GITHUB Phobos bug fixes,

$(LI $(PHOBOSGITHUB 10574): std.process execve depends on environ pointer not changing)
)

Now needs macros defined in changelog/changelog.ddoc to be useful.

I think I found the bugzilla one in dlang.org/dlang.org.ddoc but I'm not sure if that is the place to add the (DMD|PHOBOS)GITHUB ones!?

[ibuclaw]

Isn't bugstitle going to be identical to the bugzilla macro?
https://github.com/dlang/dlang.org/blob/4c5af3460f7e75974a32fd4f62adf470a54b88de/changelog/changelog.ddoc#L41

And for the githubxxx ones, I think first define GITHUB (or GITHUB_ISSUE) as the base URL macro, then the others are to the effect of

DMDGITHUB = $(GITHUB dmd,$1)

See also:
https://github.com/dlang/dlang.org/blob/4c5af3460f7e75974a32fd4f62adf470a54b88de/changelog/changelog.ddoc#L67