-
Notifications
You must be signed in to change notification settings - Fork 174
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
Conversation
@cdancy - I will be adding more commits for the queueApi changes |
@Dhivyaa21 sounds good. Just ping me and let me know when you're ready for code review. |
@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; |
There was a problem hiding this comment.
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 + "}") |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(); | ||
} |
There was a problem hiding this comment.
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?
- Jenkins URL style:
job/folderA/job/folderB/job/jobName
- 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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
public void testDeleteFolder() { | ||
RequestStatus success = api().delete(null, "test-folder"); | ||
assertTrue(success.value()); | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :-)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cdancy - sure!
This allows end user applications to configure a logger to see http transactions.
…t we can check whether or not the request contained errors or not.
… a given folder destination.
aee3711
to
9923881
Compare
@cdancy - I made a mistake rebasing off of master. Can I submit the changes for this issue in another pull-request? Sorry about that! |
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. |
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. |
Not pulling in due to PR being rebased and fleshed out elsewhere. |
No description provided.