Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use v2 of the Publishing API everywhere #832

Closed
wants to merge 14 commits into from

Conversation

floehopper
Copy link
Contributor

The two places which are using v1 of the Publishing API have been broken since this commit, because they rely on methods which were removed from gds-api-adapters in v38.0.0; the application is currently using v39.2.0. This PR removes a bunch of code around the invocations of these non-existent methods on the basis that the code is currently useless.

I'm very confident that ManualPublishingApiBulkDraftExporter and its associated code can be removed, because the rake task that was using it was removed in this commit.

I'm slightly less confident that the bin/reslug_manual_section script and its associated code can be removed, but given that it is currently broken, if someone wants to keep it, it will need to be fixed. I would also argue that it should only be kept if we write a test for it to ensure that it stays in a working state. /cc @h-lame

I did also investigate removing the use of GdsApi::TestHelpers::PublishingApi in the tests, but it appears that GdsApi::TestHelpers::PublishingApiV2#request_json_includes is not a direct replacement for GdsApi::TestHelpers::PublishingApi#request_json_including and I can't see an easy way around this.

The app is currently using gds-api-adapters v39.2.0, but these methods
were removed in v38.0.0 [1], so this code cannot possibly work! All the
tests still pass and I hope to remove the code which theoretically
invokes these methods in later commits.

[1]: https://github.com/alphagov/gds-api-adapters/blob/master/CHANGELOG.md#3800
Since the `#call` method always raises an exception, we can be sure
that it isn't being executed in production and we're justified in
simplifying it like this.
It's now obvious that this script would always fail due to the removal
of the `GdsApi::PublishingApi#put_content_item` method from
`gds-api-adapters`, so there's no point in keeping it around.
Since both `ManualPublishingAPIExporter#call` and
`ManualSectionPublishingAPIExporter#call` will always raise an
exception when their constructors are supplied with this
`export_recipient`, we can be sure that it isn't being executed in
production and we're justified in simplifying it like this.
Since an exception will always be raised within this method, we can be
sure that it isn't being executed in production and we're justified in
simplifying it like this.
Since an exception will always be raised within this method, we can be
sure that it isn't being executed in production and we're justified in
simplifying it like this.
This class is not referenced anywhere else in the code or in the specs
and in any case it's only entry point (`#export_all`) no longer works
and will always raise an exception.

It looks as if it should've been removed as part of this commit [1].

[1]: a739e78
floehopper referenced this pull request Mar 9, 2017
Going further on many of these would require rails 4 or mongoid 5 so
we're just going as far as we can for now.  For govuk_frontend_toolkit
we go as far as the same version that manuals-frontend has; it's good
to keep these in sync as we want the previews of markdown that
manuals-publisher does to be as close as possible to the "live" display
we'd get from manuals-frontend.
@h-lame
Copy link
Contributor

h-lame commented Mar 9, 2017

I think you could replace the put_content_item call in PublishingAPIRedirecter with a call to put_content on a publishing_api_v2 adapter. I'm fairly sure these are equivalent.

The bin/reslug_manual_section script is something we wrote last year in response to a support ticket, and I think we've had to run it more than once (but obvs not since I broke it with a gem bump). We get a lot of requests to do this kind of thing to HMRC manuals (which live in a different app), and it's conceivable we'd get other requests to do it on these, as you can't change the slug once it's published (I think).

I think it's probably 50:50 on whether we drop that script as you've done already, or fix the underlying thing and add tests. If we chose to fix it I suspect it would be worth looking at the ManualRelocator in lib. This object works across an entire manual rather than a single section, but it's more recent, and has some tests. Maybe a good approach would be to remove the PublishingAPIRedirecter, and replace it with some functionality extracted from ManualRelocator? I reckon it's up to you as current custodians though, as that sounds like a lot of work.

I'm 👍 on the 2nd half of removing the bulk exporter as I don't recall that being used recently.

@floehopper
Copy link
Contributor Author

@h-lame:

Thanks for the feedback - that's really helpful. I'll come back to this shortly to address your comments.

A more general question: When you have a moment, would you be able to look through the scripts in the bin directory and give us some indication of which ones are definitely needed or which ones have been run relatively recently? Alternatively could you point us at anyone else who would know?

@h-lame
Copy link
Contributor

h-lame commented Mar 9, 2017

I think most of the scripts in bin are there to help fix the result of bugs or missing functionality in the app.

For example:

delete_draft_manual and withdraw_manual work around functionality missing in the UI - you can't get rid of manuals via the UI even though the functionality exists in the system (we might need to check that these actually do the right thing wrt publishing-api). We can probably get rid of these once the functionality is in the UI - see https://trello.com/c/PnoMy4LK/73-discard-manual for a ticket about delete_draft_manual.

republish_withdrawn_document - also works around functionality missing in the UI, although it's functionality that would be more complex to resurrect - the UI doesn't currently present the user with a list of sections that have been removed from the document, so it's not a case of putting a "republish" button on the UI. We may also have to do more work to move the document out of Manual#removed_documents and back into Manual#documents. Suspect this could be got rid of and we re-write as/when requested via a support ticket.

republish_manuals is useful for when all the content needs to be resent to the publishing-api when we change the schema or so-on (for example we might need to use this if we implement https://trello.com/c/Q01pcyd3/103-send-more-details-to-rummager-from-manuals-publisher)

delete_documents_marked_for_delete, delete_duplicate_drafts and find_duplicate_documents are to help working around the fact that sometimes normal use of the app can result in duplicate manuals or sections being created. delete_documents_marked_for_delete is used when the users flag the duplicates so they are easy to remove (prefix the title with an xx I think), and the others try to find things programmatically. Getting to the bottom of the actual problem should mean we can get rid of all three of these (particularly if we also provide delete/withdraw functionality). See https://trello.com/c/R3kQxY9Z/74-duplication-bug-in-manuals for some thoughts on what the cause might be

content_model_pdf_report we've already discussed in #814

rebuild_major_publication_logs_for_manuals was a "one-off" script in response to a support ticket about the /updates page being wrong for a manual. We were always publishing change notes even for minor updates and so we had to rebuild the PublicationLog entries, that turned out to be quite painful to achieve and this was the result. It has test coverage, and we may need to do it again as it's still unclear if the current PublicationLog entries are correct (certainly at least one ticket has come in to zendesk suggesting they are, but we haven't done anything with them yet)

reslug_manual_section we've discussed this above already.

A good thing to do would be to turn these into rake tasks as then they can be run through jenkins and we'd get history of how often they're used. (See: https://github.com/alphagov/govuk-puppet/blob/f1c27d74dd0f361159bb5531473343730c692ea2/modules/govuk_jenkins/templates/jobs/run_rake_task.yaml.erb)

@floehopper
Copy link
Contributor Author

@h-lame: Thanks for taking the time to explain the scripts! 👍

floehopper added a commit that referenced this pull request Mar 10, 2017
This script relies on `ManualsPublisher#document_services` which is
been broken in a couple of different ways:

* The `AbstractDocumentServiceRegistry` class was removed in this
commit [1].
* The `ManualsPublisher#observer_registry` method was removed in this
commit [2].

In this PR comment [3], @h-lame said:

> Suspect this could be got rid of and we re-write as/when requested
> via a support ticket.

So I think it's safe to remove.

[1]: 43e2e75
[2]: 9bbf2d3
[3]: #832 (comment)
floehopper added a commit that referenced this pull request Mar 10, 2017
This script relies on `ManualsPublisher#document_services` which is
broken in a couple of different ways:

* The `AbstractDocumentServiceRegistry` class was removed in this
commit [1].
* The `ManualsPublisher#observer_registry` method was removed in this
commit [2].

In this PR comment [3], @h-lame said:

> Suspect this could be got rid of and we re-write as/when requested
> via a support ticket.

So I think it's safe to remove.

[1]: 43e2e75
[2]: 9bbf2d3
[3]: #832 (comment)
@floehopper
Copy link
Contributor Author

Closing in favour of #847.

@floehopper
Copy link
Contributor Author

Note: I've created a new issue to capture the problem with the reslug_manual_section script.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants