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

Add optional path to jobs api #13

Closed
wants to merge 27 commits into from

Conversation

Dhivyaa21
Copy link
Contributor

No description provided.

@Dhivyaa21
Copy link
Contributor Author

@cdancy - I will be adding more commits for the queueApi changes

@cdancy cdancy self-assigned this May 4, 2018
@cdancy cdancy added this to the v0.0.7 milestone May 4, 2018
@cdancy
Copy link
Owner

cdancy commented May 4, 2018

@Dhivyaa21 sounds good. Just ping me and let me know when you're ready for code review.

@Dhivyaa21
Copy link
Contributor Author

@cdancy - I think queueApi doesn't need the optional folder path. I am done with this change. Please review and let me know.

import com.cdancy.jenkins.rest.parsers.BuildNumberToInteger;
import com.cdancy.jenkins.rest.parsers.LocationToQueueId;
import com.cdancy.jenkins.rest.parsers.OutputToProgressiveText;
import com.cdancy.jenkins.rest.parsers.RequestStatusParser;
import org.jclouds.javax.annotation.Nullable;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line does not belong here, move so it is in alphabetical order with the other org.jclouds imports.


@RequestFilters(JenkinsAuthenticationFilter.class)
@Path("/")
@Path("{" + OPTIONAL_FOLDER_PATH_PARAM + "}")
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit confused by this as it's not something the user can control at runtime. Can you explain the reasoning here?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the one comment stopping this PR from moving forward. If you could explain your thinking here that would be great.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just thought the OPTIONAL_FOLDER_PATH_PARAM would be common for all the jobAPIs.(Like a global variable?)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is the base path and everything builds on top of it. I believe the idea is to pass this on as a method option and not set it on the base path. Do things work for you locally when you do this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the live tests passed for me.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so this is like setting the @Path("/queue") at the class level for the QueueApi interface:

@Path("/queue")
public interface QueueApi {
@Named("queue:queue")
@Path("/api/json")
@SelectJson("items")
@GET
List<QueueItem> queue();

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martinda exactly. It's the starting path and we build on top of it.

Do you think there could be a problem doing this?

@Dhivyaa21 I guess I don't see the reason why we would do it in 2 places is all unless I'm missing something.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cdancy - Okay.. I think I am getting it. I made the base path a variable here whereas it is a constant in the other class. I am just trying to understand why can't the base path be a variable.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Dhivyaa21 because we can't dynamically affect that at runtime so to me it does not make sense to have that be a variable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cdancy I have modified the code and added a commit to this pull-request. Please review.

public HttpRequest filter(final HttpRequest request) throws HttpException {
final String requestPath = request.getEndpoint().getRawPath().replaceAll(SCRUB_NULL_PARAM, EMPTY_STRING);
return request.toBuilder().fromHttpRequest(request).replacePath(requestPath).build();
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cdancy @Dhivyaa21 How should the user specify the optional path when calling the JobsApi methods?

  1. Jenkins URL style: job/folderA/job/folderB/job/jobName
  2. Simple path expression: folderA/folderB/jobName

This method looks like the right place to convert the simple path expression to the URL. It would make life easier for the user. What do you think? Should it be this method, or should it be in another implementation of HttpRequestFilter?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm ... I suppose both are possible right? I'm open for suggestions here and yes this would be the best place IMO.

Copy link
Owner

@cdancy cdancy May 10, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't be too bad to do something like: ensure each "name" is preceded by job and if not then inject into string.

@cdancy cdancy modified the milestones: v0.0.9, v0.0.10 May 9, 2018
public void testDeleteFolder() {
RequestStatus success = api().delete(null, "test-folder");
assertTrue(success.value());
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to tell programmatically if the plugin is installed so that we can potentially skip these tests if it isn't?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe as part of a first test in this chain of tests check if we can create a folder and if we can't then skip the rest of the tests?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a REST API to query the list of plugins, documented here, and grep'ing for the folder plugin looks like this in curl:

curl -X GET \
    "http://localhost:8080/pluginManager/api/xml?depth=1&xpath=/*/*/shortName|/*/*/version&wrapper=plugins" |
    grep -o -i -P "folder.*?<\/version>"

Feels like an API to add to jenkins-rest :-)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I actually think this is a requirement before we push forward with this PR. I'll see if I can knock something out quick unless others want to do so.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah.. I like this idea to check if the plugin exists before we write the test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anddd POSTing to http://localhost:8080/pluginManager/installNecessaryPlugins would install the missing plugins as well. The http://localhost:8080/pluginManager/api page explains all the APIs.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we could check if it's present, and if not, then attempt to install it. Very awesome.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PullRequest for PluginManagerApi put together HERE. Have a look guys and let me know what you think. It only supports the listing of the plugins which should be enough to get us around this issue and then give us something to build upon.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Dhivyaa21 I've merged that PR to master if you want to rebase off of that and use the new PluginManagerApi.plugins() call to test if a given plugin is available.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cdancy - sure!

@Dhivyaa21 Dhivyaa21 force-pushed the add-optional-path-to-jobsApi branch from aee3711 to 9923881 Compare May 11, 2018 21:09
@Dhivyaa21
Copy link
Contributor Author

@cdancy - I made a mistake rebasing off of master. Can I submit the changes for this issue in another pull-request? Sorry about that!

@cdancy
Copy link
Owner

cdancy commented May 11, 2018

Of course! I'm actually sending in another commit to implement the installNecessaryPlugins endpoint. It works but returns an http 200 no matter if the plugin ID is valid or not. If it is it will eventually install otherwise it will eventually fail. Not great but it works when it works.

@cdancy
Copy link
Owner

cdancy commented May 11, 2018

Change is now pushed to master. It might be better to attempt to install the plugin and then spin for some amount of time (maybe 5 minutes?) on the "list plugins" endpoint in hopes that it will eventually become installed.

@cdancy
Copy link
Owner

cdancy commented May 14, 2018

Not pulling in due to PR being rebased and fleshed out elsewhere.

@cdancy cdancy closed this May 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants