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

[WIP] Porting OctoTools to FAKE 5 #2048

Merged
merged 8 commits into from
Aug 18, 2018
Merged

[WIP] Porting OctoTools to FAKE 5 #2048

merged 8 commits into from
Aug 18, 2018

Conversation

queil
Copy link
Contributor

@queil queil commented Aug 3, 2018

Description

An initial PR just to get some feed back.

TODO

  • New (API-)documentation for new features exist (Note: API-docs are enough, additional docs are in help/markdown)
  • [] unit or integration test exists (or short reasoning why it doesn't make sense)
  • (if new module) the module has been linked from the "Modules" menu, edit help/templates/template.cshtml, linking to the API-reference is fine.
  • (if new module) the module is in the correct namespace
  • (if new module) the module is added to Fake.sln (dotnet sln Fake.sln add src/app/Fake.*/Fake.*.fsproj)
  • Fake 5 API guideline is honored

@queil queil mentioned this pull request Aug 3, 2018
Copy link
Member

@matthid matthid left a comment

Choose a reason for hiding this comment

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

Looks quite good already

| Push of PushOptions

/// Complete Octo.exe CLI params
[<CLIMutable>]
Copy link
Member

Choose a reason for hiding this comment

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

Generally we remove CLIMutable is that required here?

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 do not think so. Will double-check and remove if not.



/// Default server options.
let serverOptions = { Server = ""; ApiKey = ""; }
Copy link
Member

Choose a reason for hiding this comment

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

typically we set options via callbacks, therefore we usually mark defaults "private" or "internal" as they are not really required by the user

let serverOptions = { Server = ""; ApiKey = ""; }

/// Default options for 'CreateRelease'
let releaseOptions = {
Copy link
Member

Choose a reason for hiding this comment

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

Same here (and others)

WorkingDirectory = "" }

/// [omit]
let optionalStringParam p o =
Copy link
Member

Choose a reason for hiding this comment

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

Such helpers should all be private/internal if not used by the consumer

/// ## Parameters
///
/// - `setParams` - Function used to overwrite the OctoTools default parameters.
let Octo setParams =
Copy link
Member

Choose a reason for hiding this comment

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

We would choose a different name as currently the usage is Octo.Octo in fake 5 we opt for Octo.run or Octo.exec or whatever the correct verb is.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The full list of Octo.exe verbs is quite long. Shouldn't I create many verbs instead of just run:

let deployRelease setParams = ... 
let createRelease setParams = ...

Called like:

Octo.deployRelease (fun ps -> {ps with ...}
Octo.createRelease (fun ps -> {ps with ...}

Copy link
Member

Choose a reason for hiding this comment

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

That depends on the representation of the setParams type. Both styles are valid according to the fake 5 guideline. I guess if the verbs are quite different then different functions with different parameter records is easier for users. If parameters are very equal across the different verbs than sharing (or only having a single function) makes more sense.

I'll leave that up to you as I'm not familiar with octo.exe.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, there is only a handful of common options. Also the verbs do actually do quite different things. So I will go for separate verbs then.

@queil
Copy link
Contributor Author

queil commented Aug 4, 2018

Thanks for the feed back. I will fix the issues soon.

Making Channel available in deployRelease and deleteReleases.
@matthid
Copy link
Member

matthid commented Aug 5, 2018

Also note: There is no need to implement all verbs right now. It's completely acceptable to only implement the subset you need "right now" or we supported previously? If somebody needs an additional verb we can add them on-demand or he can send its own PR.

@queil
Copy link
Contributor Author

queil commented Aug 5, 2018

Yes, I agree. I only added whatever was implemented there already. The only new feature is adding Channel parameter to deployRelease and deleteReleases which I need "right now" indeed.

@queil
Copy link
Contributor Author

queil commented Aug 5, 2018

@matthid I am happy with the code now.

@matthid
Copy link
Member

matthid commented Aug 5, 2018

@queil Yes looks good, just the couple todos left from the PR todo list (some organizational and documentation stuff).

@queil
Copy link
Contributor Author

queil commented Aug 5, 2018

Cool, I'll go through that tomorrow. Thanks.

@matthid
Copy link
Member

matthid commented Aug 11, 2018

ping :)

@queil
Copy link
Contributor Author

queil commented Aug 11, 2018

I've just committed a couple of changes regarding the docs. The only missing point is unit/integration tests. I do not think it make much sense in this kind of tool. The only tests I can think of would be to verify whether for a given set of parameters a correct command string is generated. What do you think?

@matthid
Copy link
Member

matthid commented Aug 18, 2018

I looked through it twice and I don't think there is anything to add here, good job and thanks a lot!

@matthid matthid merged commit b77828e into fsprojects:release/next Aug 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants