---

This section details on the original issue you should resolve

<issue_title>Deprecate support for usethis ci</issue_title>
<issue_description>It was an interesting experiment but Bitbucket pipelines is quite limited and testing it is hard. Issues like #1312 scare me a bit.

I'm dreading adding support for GitHub actions, which has a completely different sort of ecosystem, including externalized repos. It is quite dangerous from a security perspective (zizmor would need to be integrated into the test suite to provide assurance that the files usethis generates are secure, but even then it feels like a weak guarantee).

I'm considering the trade-off of continuing to support CI config architecturally versus giving up on it and keeping usethis focused on pure Python config, and leaving CI for the bespoke ways that people like to configure it.

In a commercial context, CI often uploads results to internal servers etc. so it will almost never be fully abstracted in the way that usethis envisages.

Most tools run through pytest and prek/pre-commit so the extra benefit of adding CI config seems very low compared to the complexity of what I'm needing to build/maintain. And it's really quite orthogonal to the main objectives of this project.

It's also a maintenance burden, as schemas change, I have to bump them regularly e.g. #412 #926, #1299, etc.

R usethis has "questioning" lifecycle marked for CI config and doesn't have it for GitHub. And I don't think it tries to do what usethis Python is trying to do right now in terms of dynamic population of the CI config file.
</issue_description>

Comments on the Issue (you are @copilot in this section)

@nathanjmcdougall The more I think about this, the more I think it's the right move.

I think usethis adds the most benefit for routine, low cognitive load tasks where users are copy-and-pasting stuff from the documentation. CI is not like that.

CI is quite bespoke. Even for Bitbucket pipelines, I'm already making assumptions about the way the user does things (sticking everything in one pipeline; the default pipeline). We'll always assume a protocol/convention for job/step names which is dubious. GitHub is even more free-for-all and the CI config is not necessarily confined to one file. Then there's release pipelines etc. which are still bound up with the project. I think basically this is just too hard. I don't have the time or the desire to try and get usethis to tackle it.

Best practices for CI change a lot. Whereas tools try to avoid breaking changes, I fear that major architectural decisions around best practice may change over time.</comment_new>
<comment_new>@nathanjmcdougall
Another thought - performance will improve by removing CI integrations.

OK, I think I'll put in a deprecation warning in usethis 0.19.0 that usethis ci will be removed in usethis 0.20.0, and mention this is in the docs. At v0.20.0, I will keep all the existing code infrastructure in place but remove the actual CLI command, replacing it with a message requesting user feedback on this tracker issue. I should also open a ticket at that point to write docs explaining why usethis doesn't cover CI. And from then on I will just be pragmatic about removing anything I don't see value in keeping.

I'm also going through the backlog labelling things as ci so that I can close them as unplanned but still be able to come back to them as ideas if we ever revisit it.

@nathanjmcdougall Should use the docs here for how to deprecate a CLI command using typer: https://typer.tiangolo.com/tutorial/commands/help/#deprecate-a-command

Basically just the @app.command(deprecated=True) command. We should also add a warn_print call explaining specifically when the command will be deprecated (i.e. the version). Tests can be updated correspondingly to pass them.</comment_new>