To start off, it is most likely that #228 will be merged in before this change (which will cause conflicts; but I do not mind correcting these conflicts if needed).

I have no problem with the idea of supporting a wildcard to map to detected assets which may be generated by other extension. I would like to also try this out to actually see it being performed (even though the idea makes sense after reading the referenced PRs). I am a bit hesistent in having this supported_image_types list though. Sphinx does have some mime definitions inside their images.py implementation -- I wonder if there is something we could be doing with this to prevent this extension to trying to manage supported image types (although, I have no problem definition a separate independent list to whitelist or blacklist image types based off official documented Confluence supported image types).

Note that due to other issues being addressed in this extension, the expected window for this feature is planned around end-of-year (2019; see this comment for more details).

I have a similar usecase. I build both HTML and PDF output from a single source. To make images (especially diagrams) display as crisp as possible, I use SVG diagrams for HTML output and PDF diagrams for inclusion into PDF output.
The image is included using .. figure:: images/diagram.*. The actual file (diagram.svg or diagram.pdf) that is included depends on the builder that is used.

Sphinx already has code that handles an asterisk in the file extension: https://github.com/sphinx-doc/sphinx/blob/01f8dad160d206a48302b1bcd91b4e0bc36e8a10/sphinx/builders/__init__.py#L186. This replaces the * in the filename based on the supported_image_types of a writer.
This is called by the default writers in Sphinx but not by confluencebuilder.I can make my usecase work by adding a suitable supported_image_types and adding a call to self.post_process_images(doctree) in prepare_writing() here:

@jjcaballero would that solve your usecase? It is much less code than this PR and will keep maintenance of the code that finds the correct file the responsibility of Sphinx, not confluencebuilder.

I wonder if there is something we could be doing with this to prevent this extension to trying to manage supported image types

@jdknight As Confluence content ends up as HTML anyway, one could assume that the image formats that are supported are as the same for the HTML builder. The list of supported images can then be defined in code with:

from sphinx.builders.html import StandaloneHTMLBuilder 

...

class ConfluenceBuilder(Builder):
    supported_image_types = StandaloneHTMLBuilder.supported_image_types

@jessetan your approach seems cleaner and works for my use case too.
Do you plan to do a PR for that or should I include it here?
I would like to try to keep the expected window for this feature mentioned by @jdknight (end of the year 2019)

@jjcaballero if you are willing, it would be great if you could make the changes in this PR. It would save me some work and you have the testcases ready.

After my previous comment, I've found the best place to call self.env.app.builder.post_process_images(doctree) is before processDocument in

So far I have found only one downside; builds fail if the PlantUML Sphinx extension is used (https://github.com/sphinx-contrib/plantuml/). The image nodes inserted by that plugin never get a candidates attribute.
I've worked around this by adding the following before the call to post_process_images

        # Verify every image has a 'candidates' attribute with key '*'
        # This is normally added by Sphinx' ImageCollector, but is not called
        # by sphinxcontrib.plantuml for some reason
        # https://github.com/sphinx-doc/sphinx/blob/089046979f2b84cf850ee95776d10fe9fd9a77e9/sphinx/environment/collectors/asset.py#L43
        for node in doctree.traverse(imageNode):
            if 'candidates' not in node:
                node['candidates'] = { '*': node['uri'] }

There must be a better way to do this, but I haven't had time to delve into this issue any deeper. It's probably not necessary to try to fix that in this PR.

@jdknight the pull request should be ready now to review/merge. Thanks.

@jessetan eventually, I placed self.post_process_images(doctree) in prepare_writing() from builder.py. As this method belongs to the parent class sphinx.Builder, IMO it is clearer to call it directly from the child class ConfluenceBuilder, instead of using the self.env.app.builder from the assets.py module.

I agree that the plantuml issue does not need to be addressed here and I hope it does not stop this PR :-)

@jjcaballero this works for my usecase. Thanks for your effort.

Go time; thanks all! Merged into master; available next stable.