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

[FIX-JENKINS-38805_User_can_run_parametrised_pipeline] #692

Merged
merged 34 commits into from
Jan 17, 2017

Conversation

scherler
Copy link
Collaborator

@scherler scherler commented Jan 10, 2017

Description

See JENKINS-38805.

  • extending the RunButton to be able to start parametrised jobs where ever the "old" RunButton has placed
  • Refactor parameter implementation to use mobx
  • move parameter into core

state of the nation

The feature is ready to review and playing around.

ATH coverage

jenkinsci/blueocean-acceptance-test#100

Current master ATH run on the branch https://ci.blueocean.io/job/ATH-Jenkinsfile/job/master/894/
Current branch ATH https://ci.blueocean.io/job/ATH-Jenkinsfile/job/master/919/

Next steps

  • create ATH to cover the basic steps with input parameter

Submitter checklist

  • Link to JIRA ticket in description, if appropriate.
  • Change is code complete and matches issue description
  • Appropriate unit or acceptance tests or explanation to why this change has no tests
  • Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.
  • Ran Acceptance Test Harness against PR changes.

Reviewer checklist

  • Run the changes and verified the change matches the issue description
  • Reviewed the code
  • Verified that the appropriate tests have been written or valid explanation given

@reviewbybees

…c version that works with input parameter, still have some real rough edges to fix
changeParameter(index, event) {
// console.log('onChange', index, event);
const originalParameters = this.state.parameters;
originalParameters[index].defaultParameterValue.value = event;
Copy link
Contributor

@cliffmeyers cliffmeyers Jan 10, 2017

Choose a reason for hiding this comment

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

Per discussion in Gitter, it looks like the value property is observable here, so modifying it outside of @action decorator or action() function will throw this error when mobx useStrict(true) has been set. I believe that is set globally in core-js right now.

This may seem annoying but in a way I think it's good because it makes it very explicit when state change happens. Observable / data binding can be a slippery slope whenever any code can modify the data when there are shared references.

If you refer to core-js ToastService that's a very simple example where modification of an array is managed by two different @action methods. I think this is a good practice so that we're explicit and consistent of where we do state mutations.

On the other hand, if I understand the code correctly, you are pulling metadata about the input parameters from a job, then rendering them dynamically for user modification when launching a run. To me, you don't want to modify the underlying job / pipeline data in the data model during this user interaction. So I think what you probably want to do is clone the data here that drives the input parameters. If you still need advantages of observability and UI data binding, I write a quick class which encapsulates the form state and is build from a clone of the pipeline data. That way this data can be modified freely without changing the underlying data model.

@michaelneale
Copy link
Member

great to see this stuff kick off !

const cancelButton = (<a title={cancelCaption} onClick={() => this.cancelForm()} className="btn inputStepCancel run-button btn-secondary" >
<span className="button-label">{cancelCaption}</span>
</a>);
return (<ModalView
Copy link
Contributor

@i386 i386 Jan 11, 2017

Choose a reason for hiding this comment

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

@scherler is this the dialog component that @sophistifunk built or a new impl of the Modal? I believe we should be using the dialog not a new component (cc @brody) See https://issues.jenkins-ci.org/browse/JENKINS-39371

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@i386 that is Modal view from jdl. I was not aware about the dialog component. will use that instead.

* In case you want to register a new mapping you need to edit './parameter/index' to add a new mapping
* and further in './parameter/commonProptypes' you need to include the new type in the oneOf array.
*/
export default class InputParameters extends Component {
Copy link
Member

Choose a reason for hiding this comment

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

tiny thing, but I worry that the name "Input" may confuse people looking at code for input vs params (they are very similar). It says parameters so this is ok... perhaps "ParameterForm" or something? just a suggestion. Nice commentary ;)

Copy link
Collaborator Author

@scherler scherler Jan 11, 2017

Choose a reason for hiding this comment

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

noted, the whole thing needs a second iteration to remove some code redundancies. I created the PR to get feedback from cliff.

@i386
Copy link
Contributor

i386 commented Jan 11, 2017

Thanks Thor :)

onNavigation={onNavigation}
innerButtonClasses="btn-secondary"
/>
<ParametersRunButton
Copy link
Member

Choose a reason for hiding this comment

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

So this contains the regular run button if I read it correctly.
This is maybe a little bit confusing name wise - it probably still should be "RunButton" but then it has components in it for normal and parametrised run button I think.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@michaelneale yes it contains the regular RunButton and shows it when no parameters are detected.

Regarding naming ParametersAwareRunButton had been to long but that would be the most specific name.

@@ -114,7 +85,7 @@ export default class InputStep extends Component {
error.response = response;
throw error;
}
return response;
return response.json();
Copy link
Member

Choose a reason for hiding this comment

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

curious about this change - how did it work before?

@michaelneale
Copy link
Member

good progress, did a quick look:

screen shot 2017-01-12 at 8 31 45 pm

Also, in that case, @brody @i386 - should it not be "abort" but "cancel" or "close" as at that point it isn't actually running, so abort doesn't make as much sense (I don't know what the design showed).

@i386
Copy link
Contributor

i386 commented Jan 13, 2017

Few things here @scherler:

  • That has to be Cancel instead of Abort
  • The dialog is too thin. @brody can you please provide guidance here?
  • I realise that there is a z-index problem that is creating the line across the dialog. This needs to be fixed in this PR or at least immediately after.
  • The dialog type you are using will overflow the content area of the dialog and always show the buttons. Is that how you are using it? I believe @sophistifunk allows the dialog to show buttons in a standard way and we should be using that.

@brody
Copy link

brody commented Jan 13, 2017

@scherler the design in zeplin is 464px wide. At least make it 450px wide and it'll be beautiful.

@scherler
Copy link
Collaborator Author

The dialog type you are using will overflow the content area of the dialog and always show the buttons. Is that how you are using it? I believe @sophistifunk allows the dialog to show buttons in a standard way and we should be using that.

I am using it as shown in the related story: https://github.com/jenkinsci/jenkins-design-language/blob/master/src/js/stories/DialogStories.jsx#L58

https://github.com/jenkinsci/blueocean-plugin/pull/692/files#diff-e999489b5e8809d41a4a6ba443345688R134 meaning as I understand I am using it in the standard way.

@scherler
Copy link
Collaborator Author

I am starting now to make it more appealing.

@scherler
Copy link
Collaborator Author

scherler commented Jan 13, 2017

screenshot from 2017-01-13 20-41-40

@brody @i386 current stand

…core and extract input parameter from runnable. exporting the parameterRunButton as RunButton so all current usage support parameters out of the box. Tweak design of favorites to support parameterized starts.
@scherler scherler changed the title [JENKINS-38805_User_can_run_parametrised_pipeline] WIP implement basi… [FIX-JENKINS-38805_User_can_run_parametrised_pipeline] Jan 14, 2017
@ghost
Copy link

ghost commented Jan 14, 2017

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

@i386
Copy link
Contributor

i386 commented Jan 15, 2017

@scherler the "Build" button should be "Run"

@michaelneale
Copy link
Member

Getting some test failures @scherler - worth looking into

})
}
</Table>
{ runs.length > 0 &&
Copy link
Member

Choose a reason for hiding this comment

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

Is there any real diff here? It looks like formatting only, but its a dozen odd lines so hard to see - is there some tool doing that as it is a bit annoying as git can't tell it apart from real refactoring.

<button disabled={this.pager.pending || !this.pager.hasMore} className="btn-show-more btn-secondary" onClick={() => this.pager.fetchNextPage()}>
{this.pager.pending ? t('common.pager.loading', { defaultValue: 'Loading...' }) : t('common.pager.more', { defaultValue: 'Show more' })}
</button>
{ runs && runs.length > 0 &&
Copy link
Member

Choose a reason for hiding this comment

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

ditto with whitespace only changes???

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah sorry about that.

@michaelneale
Copy link
Member

very nice - working great so far @scherler!

Copy link
Member

@alecharp alecharp left a comment

Choose a reason for hiding this comment

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

French translation advices

@@ -3,6 +3,9 @@ login=Connexion
logout=D\u00e9connexion
Not.found.heading=Page non trouv\u00e9e (404)
Not.found.message=Jenkins n'a pas pu trouver la page que vous recherchiez. V\u00e9rifiez l'URL pour des erreurs ou appuyez sur le bouton de retour.
parametrised.pipeline.cancel=Annuler
parametrised.pipeline.header=Input indispensable
parametrised.pipeline.submit=Lancer
Copy link
Member

Choose a reason for hiding this comment

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

I would say "Démarrer"

@@ -3,6 +3,9 @@ login=Connexion
logout=D\u00e9connexion
Not.found.heading=Page non trouv\u00e9e (404)
Not.found.message=Jenkins n'a pas pu trouver la page que vous recherchiez. V\u00e9rifiez l'URL pour des erreurs ou appuyez sur le bouton de retour.
parametrised.pipeline.cancel=Annuler
parametrised.pipeline.header=Input indispensable
Copy link
Member

Choose a reason for hiding this comment

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

I would say "Entrée(s) indispensable" as "Input" is not a true French word. But the job configuration use the terms "parameters" so we could say "Paramètre(s) indispensable", which would be better for the configuration -> usage understanding.

Copy link
Member

@alecharp alecharp left a comment

Choose a reason for hiding this comment

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

I think it's better this way.

@scherler
Copy link
Collaborator Author

@scherler
Copy link
Collaborator Author

@scherler
Copy link
Collaborator Author

@scherler scherler merged commit d873acc into master Jan 17, 2017
@scherler scherler deleted the JENKINS-38805_User_can_run_parametrised_pipeline branch January 17, 2017 15:46
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.

6 participants