Execute 1build from specified configuration file

[gopinath-langote]

Description

Currently1build only allows executing commands from the current directory. Sometimes developers have to switch the directory to execute any command.
Allowing the user to execute a command from specified will help to reduce the two steps.

Flag

-f
--file

Acceptance Criteria

1. Root/Exec/Set/Unset Command

- Given a configuration file to execute a command from with flag `-f file_name`, 1build should execute a command from that.
- If no file specified 1build will execute continue to run with the current directory file
- If a specified file with `-f` not present - 1build should give an error

2. List Command

- Given a configuration file to execute a command from with flag `-f file_name`, 1build should list commands from that.
- If no file specified 1build will execute continue to list from the current directory file
- If a specified file with `-f` not present - 1build should give an error

3. Delete Command

• Init will not have -f flag/option. As it doesn't make sense to delete the file using one build instead developer can delete it by rm.

4. Init Command

• Init will not have -f flag/option.

Out of scope

• Accepting files with a name other than 1build.yaml

Example

    1build -f ~/some_project/1build.yaml test
    1build -f ~/some_project/1build.yaml set cmd "some command"
    1build -f ~/some_project/1build.yaml unset cmd 
    1build -f ~/some_project/1build.yaml list

[vkumbhar94]

Perhaps, passing file path may become tedious.
We could also think about context based configurations. Instead of passing file path, we can pass context name and 1build will pick appropriate file path from context config file.
Contexts will also help us to store if there are any other params also.

[TimDurward]

Could you assign to me @gopinath-langote . I'd like to try implementing this feature. Can we scope to the command argument -f and perhaps extend (at a later iteration) or create a new issue in regards to @vkumbhar94's suggestion.

[gopinath-langote]

@TimDurward Sure. Please go ahead.

I have updated the Acceptance Criteria for the issue. Let me know if need any clarification on this.

About decision/tech decisions please feel free to ask here in the thread.

Let me know the scope of the issue looks good to you.

[TimDurward]

@gopinath-langote Your example list shows -f as a global persistent flag. However I do agree with this implementation, I see some conflicts, especially with the scope requirement of excluding delete and init for --file flag.

A couple design ideas

1. Scope --file to a local flag (This might not be the best solution as it would most likely ignore user config commands, although maybe you have an idea around that flaw?)
2. Scope --file to global (as you originally suggested [i.e 1build --file /path/to/config.yaml test]), but this would also include the commands you would not want the file flag to inherit (i.e delete, init). We could (possibly) hack the subcommands (delete, init) to ignore the file flag, but this wouldn't be so graceful and would introduce a design flaw.)

Me personally, I suggest we scope --file to global, which would mean all commands have the availability to specify the config file. However we could add default values to the commands we'd otherwise be excluding (delete, init), but with the understanding that users can specify a file on all commands at root level.

[gopinath-langote]

@TimDurward Thanks for the detailed analysis. I missed that part of the analysis.

Yes. After considering all options. I agree to use --file to global flag.

About delete and init - Actually It is a good idea to support those commands also to pass the -f flag.

Example delete the file passed or init the configuration in given file path.

What do you think?

[gopinath-langote]

@TimDurward This will increase the scope of this issue.

We can split the issues to support -f flag per command. Let me know your thoughts.

[TimDurward]

@gopinath-langote I think we can scope to one issue.

I currently have all commands, and custom commands working with the new -f/--f file flag. What I didn't realize is, during execution, we'd need to also change directories within the subshell.

1build/cmd/exec/exec.go

Line 109 in 8fb9101

s.SetDir(onebuildDir)

I'm not finished with the Pull Request yet, I still need to dig in to the tests (not my strongest part 😆 ), but what I would like is maybe a quick review to see if we're both on the same page, and maybe you can try it out locally.

You can take a look at it here:
#194

[gopinath-langote]

@TimDurward

Thanks for the PR.

My suggestion was to not to setDir for the command vs pass the absolute path of 1build.yaml to read.

This way - we only need to change reading part everything else remain same. And also gives flexibility of extending functionality.

Or is this for setting directory as working directory?

I am not quite sure whether we should set working directory to specified file path or not.

Should we go ahead with using current execution directory and see later if we need to change the working directory?

WDYT?

[TimDurward]

@gopinath-langote
This sets the directory of the current shell session that get's created during execution. The directory is defined by resolving the path location of the 1build configuration file.

I guess that was my natural assumption that a user would want to run their 1build commands in the same context of the configuration file.

For example:
You're at your $HOME dir, and run 1build -f ~/dev/user/project/1build.yaml test, you wouldn't be testing a project at the home directory, you'd be wanting the context of your projects location (where the 1build.yaml resides).

However, the adverse is, a user has common commands that aren't specific to a project and can be run in multiple projects/directories, having a generic 1build configuration file could serve it's purpose, which in this case, having 1build change the directory (where the config file is located) to execute commands would not be ideal.

I'm curious what your opinion is and what you'd learn towards; from reading your last message - your current suggestion is not to implement changing directories, as that would increase scope of work, but, for what it's worth that work is pretty much done.

I can go either way. 😄

[gopinath-langote]

@TimDurward Got your point.
This was my original intention.

However, the adverse is, a user has common commands that aren't specific to a project and can be run in multiple projects/directories, having a generic 1build configuration file could serve it's purpose, which in this case, having 1build change the directory (where the config file is located) to execute commands would not be ideal.

But I agree with you. Changing directory for the command will give clear idea for developer which context they are running command in.

Please go ahead with setting working directory to specified path

[dzhg]

Hi @gopinath-langote & @TimDurward , I'm currently doing some POC in our organization.

One of the potential use case is, we put 1build configuration files in different directories for different environments (we may have different environments for build and deployment). For example:

For our internal test environment
<PROJECT_ROOT>/.1build/sandbox/1build.yaml

project: abc
commands:
  - deploy: command for deployment to test env

<PROJECT_ROOT>/.1build/stage/1build.yaml

project: abc
commands:
  - deploy: command for deployment to stage env

You got the idea.

However, if 1build does change the working directory, it won't work for this use case.

Any suggestion?

My feeling is, 1build should not automatically change the working directory when use -f flag. Maybe, we could add another optional boolean flag to explicitly force the working directory changing?

[gopinath-langote]

@dzhg I was thinking of the same and talking few potentials developer users, understood that - Changing working directory to the specified location of a file makes sense by default.

We can improve this as a part new issue - where we can specify the working directory. By default working dir will be same as where the file exists.

[dzhg]

OK. Thanks @gopinath-langote . Sounds good.

I could help to add the other option to disable working dir changing once this -f feature is ready.

cheers.