Added missing attributes for ProjectApi

[yarisvt]

Added missing attributes to the ProjectApi

[jmini]

I don't see why we need those brackets.

I would just do this:

Suggested change

	return (this);
	return this;

[jmini]

This looks like a very good addition.

The example file project.json used in unit-test should be updated to match the changes made to the model class.

[jmini]

Can you update the file project.json?
https://github.com/gitlab4j/gitlab4j-api/blob/fe14e34f0ab11e9f06f52765f86fbc0d72caa3dd/gitlab4j-models/src/test/resources/org/gitlab4j/models/project.json
Ideally with values coming from an existing from a real REST call.

This way we would we would ensure that your changes are correctly serialized and deserialized.

[yarisvt]

Some properties are only configurable with a Premium/Ultimate gitlab server, which I unfortenately do not have access to, so I've used an accepted value based on the documentation:

option	type	value I used
use_custom_template	boolean	false
external_authorization_classification_label	string	"label"
mirror_trigger_builds	boolean	false
only_allow_merge_if_all_status_checks_passed	boolean	false
group_with_project_templates_id	integer	1

[jmini]

Some properties are only configurable with a Premium/Ultimate gitlab server, which I unfortenately do not have access to

Yes this is a pity… even for working on gitlab4j there is no good way to access such a license (or I didn't asked at the correct place)

[jmini]

Using null in those test file does not work with the unit test.

[yarisvt]

Right, I missed those. I have also removed the avatar property, since that can only be used with a multipart/form-data and I now saw that there already is a setProjectAvatar method that uses this property

[jmini]

Currently the way the models are written, we are not using @JsonProperty. There was an attempt in #1198, but it never was finished.

For consistency reason, I would not add this now.

[yarisvt]

I had to use @JsonProperty, so that the snake_case variant is used, instead of the camelCase.

With @JsonProperty:

{
  "cadence" : "1month",
  "enabled" : true,
  "keep_n" : 100,
  "older_than" : "7d",
  "name_regex" : ".*-development",
  "name_regex_keep" : ".*-main"
}

Without @JsonProperty:

{
    "cadence" : "1month",
    "enabled" : true,
    "keepN" : 100,
    "olderThan" : "7d",
    "nameRegex" : ".*-development",
    "nameRegexKeep" : ".*-main"
  }

Additionally, I also saw it used in Project itself:

    @JsonProperty("_links")
    private Map<String, String> links;

[jmini]

Why aren't you using just ContainerExpirationPolicy as parameter?

Inside the method, you could create a new Project and pass the parameter to it with withContainerExpirationPolicy(..)

If you serialise that project instance you will get the same result as with containerExpirationPolicyAttributes.toString() (since all the other fields will be null)

[yarisvt]

I tried that before, but it does not work, I keep getting this error: container_expiration_policy_attributes is invalid

According to the documentation, container_expiration_policy_attributes is used in the create/edit API to modify the policy, while container_expiration_policy is used in the list API to list the policy.

Also, there is an example which updates the policy, which uses --header 'Content-Type: application/json;charset=UTF-8'

I think it doesn't work with withContainerExpirationPolicy(..). since that request eventually uses --header 'Content-Type: application/x-www-form-urlencoded'. But the container_expiration_policy_attributes is serialized as JSON:

{
  "cadence" : "1month",
  "enabled" : true,
  "keep_n" : 100,
  "older_than" : "7d",
  "name_regex" : ".*-development",
  "name_regex_keep" : ".*-main"
}

[jmini]

The gitlab REST API is very flexible and accept the request to be either a JSON body, a regular HTTP Form Data, query parameters, …

I understand why you need a different method setProjectContainerExpirationPolicy(..) because here you are sending a project update request where the Project is serialised as Body.

My point was that ContainerExpirationPolicyAttributes model is not really necessary.

You could do something like (not tested):

    public Project setProjectContainerExpirationPolicy(Object projectIdOrPath, ContainerExpirationPolicy policy) {
Project request = new Project().withContainerExpirationPolicy(policy);
Response response = put(
                Response.Status.OK,
                request.toString(),
                "projects",
                getProjectIdOrPath(projectIdOrPath));
        return (response.readEntity(Project.class))
    }

I don't understand why this would not work.

For me request.toString() with request being a Project instance is the same as your containerExpirationPolicyAttributes.toString() where your containerExpirationPolicyAttributes instance is of type ContainerExpirationPolicyAttributes.

And it removes the need for a ContainerExpirationPolicyAttributes.

[yarisvt]

Right, I now see that there is also withParam(String name, Map<String, ?> variables, boolean required) method in GitLabApiForm which correctly sets form fields for a Map. I can just use that with container_expiration_policy_attributes, that also works.

[jmini]

Thank you very much for this contribution 🎉