GitHub App deprecation plan

[christopher-dG]

ref: #38

So here's what I'm thinking:

We'll announce the deprecation on Discourse and tell everyone to move to GitHub Actions. I'm not sure when this will be, I need to improve the new version and add tests and stuff first, I just haven't had much time to work on it.
The deprecation period can be a few months, there's no real rush. During this period, the GitHub App should:

• Completely ignore repos that already have TagBot set up as a GitHub Action
• Create pull requests to enable TagBot in all other enabled repos that are Julia packages (this can happen in bulk right at the beginning)
• When writing the final release notification comment, add a deprecation notice with reference to the Discourse post and the PR that was previously created.

After the deprecation period, we can either shut everything off, or keep it running but with no functionality except for a "Move to GitHub Actions now" message.

[davidanthoff]

We should probably coordinate a bit with https://github.com/davidanthoff/PkgButlerEngine.jl, to make sure we don't have different bots/workflows try to configure different things in repos, right?

[christopher-dG]

I think they can operate separately. The worst that can happen is the user gets one PR from TagBot and another from Butler, which isn't the end of the world.
But to be safe, TagBot can check if Butler is configured, and not do the PR in those repos.

Unrelated, but will Butler try to revert changes to a workflow file? e.g. if I manually update the TagBot configuration that Butler added, will it become "out of date"?

[davidanthoff]

Yes, butler "owns" certain files, and so those shouldn't be manually edited.

There are also some other files where it makes targeted changes, but again, those changes would come back as soon as one tries to revert them.

Detecting whether the butler version of tagbot is installed is simple, though: just check whether the file jlpkgbutler-tagbot-workflow.yml is present (like in https://github.com/davidanthoff/StringBuilders.jl/tree/master/.github/workflows).

[christopher-dG]

In that case, there could be some thinking to do on how to support configurable stuff (which TagBot is to some extent). I guess you'd have to configure each action through Butler (like putting a TagBot section in the Butler config file).
Alternatively, you could just say that Butler supports the base case and if you deviate from that, you should be managing your stuff yourself.

(biggest reason for this question is that i'd eventually like to support much more customizable changelogs)

[davidanthoff]

Yes, I've been thinking about that a lot :) I think (right now) I'm thinking that a) I'd like to keep options really minimally, so that it enforces some unity across the ecosystem, but b) when we really need options, have those in the .jlpkgbutler.toml. Another option is that if you buy into a given template, then you just have to live with the defaults for that template (or choose a different template that for example just leaves certain parts of your package alone). But I'm not super sure about any of this yet...

[christopher-dG]

Meh, different opinions. 🤷‍♂️

[christopher-dG]

Update on this: I am confident in the new TagBot's stability and ready to move along with this. The updates for the App have been written, but not deployed. I need to write a script to open PRs on all App-enabled Julia repositories with the new workflow file, and once that happens we'll just wait a few months to let people switch over. Not really sure when I have time to do the scripting but maybe ned of this month.

update: more like end of feb

[DilumAluthge]

@christopher-dG Can this be closed now that you've made all those PRs?