Add author_name and author_email to RepositoryFile

[mhagnumdw]

According to the GitLab documentation https://docs.gitlab.com/api/repository_files/#create-a-file-in-a-repository

It's possible to define the author's email address and commit author's name.

I added these parameters to the RepositoryFile and have already successfully performed local tests.

[jmini]

Are you sure the gitlab sends those attributes?

Doc: https://docs.gitlab.com/api/repository_files/#retrieve-a-file-from-a-repository

GET https://<server>/api/v4/projects/<id>/repository/files/<path>?ref=main

Is sending back:

{
  "file_name": "file.txt",
  "file_path": "file.txt",
  "size": 560,
  "encoding": "base64",
  "content_sha256": "1dd2cbbc6db2d37daa8397ef186cabcd365d366358c5130d3e321c62868a49af",
  "ref": "main",
  "blob_id": "e2a869f70d890f99ed3e86f069da49dabdac8a78",
  "commit_id": "5dd394122833ccade0474991125f73cd2514f52c",
  "last_commit_id": "af6990f7c535fd200bb9ec44acd1b99e79ee4746",
  "execute_filemode": false,
  "content": "..."
}

[mhagnumdw]

Now I've noticed a difference. The same class RepositoryFile is used to create and get a file.

When creating the file, the author_name and author_email attributes exist, but not when retrieving it.

Do you have any suggestions?

[jmini]

Good point!

I would love to have objects really corresponding to the exact JSON exchanged (request/response)… Otherwise people to a read request and complains that some values are null and are not expecting it.

If the gitlab4j client is sharing classes as you noticed this is impossible to implement… Probably we could sub-class the object used in the creation request. This would be an acceptable non-breaking change for now.

[mhagnumdw]

Taking a closer look at this GitLab API, the return object for retrieving a file is quite different (not all attributes, but several) from the input object for creating/updating a file.

This isn't right. Furthermore, if we do it as inheritance, something like RepositoryFileRequest inheriting from RepositoryFile, we'll have to do a file instanceof RepositoryFileRequest in RepositoryFileApi.createForm(RepositoryFile file, ...) to be able to add author_name and author_email.

What I'm thinking is:

• having new classes, one to represent creation and another to represent updating, faithfully representing the GitLab API contract
• deprecating the old methods indicating the reason and the alternative
• the old methods calling the new methods (maintaining backward compatibility)
• creating new methods to work with the new types for creation and updating

What do you think, @jmini?

I can implement it for you to take a look at.

PS: I'll still look at the deletion endpoint.

[mhagnumdw]

The GitLab API's response shape (GET) and request shape (POST/PUT) for repository files are quite different. Reusing RepositoryFile for both mixes read-only and write-only fields.

New approach:

• RepositoryFileCreate - input for creating a file, following the parameters from the official docs.
• RepositoryFileUpdate extends RepositoryFileCreate - input for updating a file, following the parameters from the official docs (the only extra field over create is lastCommitId).

In RepositoryFileApi:

• New overloads createFile(..., RepositoryFileCreate, ...) and updateFile(..., RepositoryFileUpdate, ...).
• The old RepositoryFile-based overloads are @Deprecated and delegate to the new ones via internal converters - backward compatible.
• createForm takes RepositoryFileCreate and uses a single instanceof RepositoryFileUpdate check to append last_commit_id.
• I think deleteFile is out of scope for this PR.
• Read methods are untouched.

@jmini , let me know what you think. The code has already been updated.