Multipart static files

[tienvx]

Depend on #340, please review it first, otherwise the tests are always failed.

[JP-Ellis]

Generally looks all good to me. Just a couple of comments (see below) before I formally approve it 👍

[JP-Ellis]

What is the purpose of this file?

[tienvx]

pactffi_with_multipart_file_v2 require path to the part's file.

Instead of creating temporary files using code, I put the content into pre-created files, so no need those ugly code.

The purpose of those files:

• full_name.txt
• image.jpg
• note.txt

are just for demo that the multipart request POST /user-profile has 3 parts: full_name, profile_image and personal_note. Nothing special about it really.

[JP-Ellis]

My oversight, I didn't fully absorb the full path name 😅 Makes complete sense!

[JP-Ellis]

And similarly, this file?

[tienvx]

Nothing special about these file. It's just for testing that I can actually send multiple parts in a multipart request.

[JP-Ellis]

Related to this PR, you mention that this PR depends on another. In case you didn't know, it is possible to point the target to another PR (as opposed to the ffi branch). This then prevents accidentally merging secondary PR without the primary PR being merged first :)

[YOU54F]

So this PR just removes the temp file creation during tests, and uses static files instead.

If I was being picky I would probably say it would be nice to follow a conventional commit standard so say

deps: update pact ffi to 0.4.9
fix: xyz

etc. However there are no current commit convention guidelines in this repo, and the original author doesn't follow those conventions, so it would unfair to block that!

and as this is fully tested, in an alpha branch, i'm okay with the lib update, especially as 0.4.8 of the ffi is missing our linux aarch64 builds and its good to get the latest release tested

[tienvx]

I will follow that standard. Thanks @YOU54F

[JP-Ellis]

If you want to read more about it, you can check it out at conventionalcommit.org

I remember when switching to this initially, it was a little weird; but now that I use it consistently, it makes git logs so much easier to parse quickly 😁 Plus there's a bunch of tooling out there that make use of a conventional commit log to generate things like changelogs.