-
Notifications
You must be signed in to change notification settings - Fork 314
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
CHEF-12417: Remove hab bldr job commands #9302
Conversation
👷 Deploy Preview for chef-habitat processing.
|
93a2eca
to
c878f7f
Compare
d3a9186
to
9b365b3
Compare
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.
The code changes per se look okay. A couple of main comments (repeated a few times for each sub command) -
- Being a bit more explicit about unsupported features in the CLI help.
- We don't have to handle the options for individual
job <subcommand>
@@ -61,6 +64,9 @@ pub enum Job { | |||
} | |||
|
|||
/// Get the status of one or more job groups | |||
/// | |||
/// NOTICE: Public Builder Build Functions are no longer supported. Please reach | |||
/// out to your account team if you were using these features. | |||
#[derive(ConfigOpt, StructOpt)] | |||
#[structopt(name = "status", no_version)] | |||
pub struct JobStatus { |
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.
Not sure whether these arguments make sense any more for example if one runs hab bldr job status
, a user is shown CLI parsing error (which is not same as the NOTICE above). When this is anyways not supported, don't think we need to deal with these options anymore.
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.
As discussed in daily and now noted in commit leaving these so that any scripting done leveraging these commands fail with the failure message instead of "missing option".
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 tried locally something - and it works fine - If we change
#[structopt(name = "status", no_version)]
to
#[structopt(name = "demote", no_version, settings = &[AppSettings::ArgRequiredElseHelp])]
This avoids one round trip for user to get the NOTICE: ...
Sorry, I didn't know about this option before, I happened to come to know about this option while working on #9330.
I think it's a good idea to include that.
I am okay if you want to leave it as well.
bfd6bfb
to
c12449c
Compare
- Adds a NOTICE to doc for the following commands - hab bldr - hab bldr job - Prefixes REMOVED: to doc for the following subcommands - hab bldr job - hab bldr job {cancel,demote,promote,start,status} - Removes implementation and returns error for these subcommands - hab bldr job {cancel,demote,promote,start,status} These subcommands that had their implementation removed still require their options to ensure that any scripting leveraging those subcommands fail predictably with the messaging we've added. Signed-off-by: Jason Heath <jh@jasonheath.com>
c12449c
to
db9a465
Compare
So it's the CPP action that's failing on this. Pushing over that since there's no CPP in our project. Something we ought to fix at some point. |
Replaces hab bld job cmds with a message to contact account team