Managed builds support added #40
Conversation
cmd/fossa/config.go
Outdated
| Server string | ||
| Fetcher string // for now we don't allow users to set this | ||
| Project string | ||
| Revision string |
There was a problem hiding this comment.
A few notes here:
- I'm not sure how I feel about changing this because we already have customers using
fossalive and this is potentially a breaking change to their configurations. - That said, I don't think anybody sets the
Locatorfield, so changing this should be relatively safe. - Users can already specify
projectandrevisionvia command line flags. This struct only defines the format of the configuration file, and is different from the shape of the configuration struct we use internally. I think I might actually prefer taking outLocatorand not putting anything else in -- when would anybody ever want to specify revision via configuration file?
cmd/fossa/config.go
Outdated
| func initialize(c *cli.Context) (cliConfig, error) { | ||
| var config = cliConfig{ | ||
| apiKey: c.String("api_key"), | ||
| fetcher: c.String("fetcher"), |
There was a problem hiding this comment.
If we don't want users to set this, we should probably not include it as a flag.
cmd/fossa/upload.go
Outdated
| if config.project == "" { | ||
| analysisLogger.Fatal("could not infer project name from either `.fossa.yaml` or `git` remote named `origin`") | ||
| if config.revision == "" { | ||
| analysisLogger.Fatal("could not infer revision name from either `.fossa.yml` or `git` remote named `origin`") |
There was a problem hiding this comment.
[nit] These log statements should actually be Sentence case.
|
I understand this is WIP. I think the ideal flow is to use the custom response code to initiate a project creation workflow, so if we run into a case where we need to create a managed project, the CLI will ask the user for some info and it will write to config. We should automatically figure out how to generate an id, maybe we could do something like
|
5d8bcc2 to
6d3d3d4
Compare
83e29bd to
4d9806c
Compare
| if revision == "" { | ||
| revision, err := repo.Head() | ||
| if err == nil { | ||
| c.CLI.Revision = revision.Hash().String() |
There was a problem hiding this comment.
will this get written to config in fossa init? we don't want to write the revision unless it was specified in config
config/config.go
Outdated
| Modules: modules, | ||
| Debug: c.Bool("debug"), | ||
| ConfigFilePath: c.String("config"), | ||
| ExistingProject: c.Bool("existing_project"), |
There was a problem hiding this comment.
This shouldn't be a separate flag -- instead the user should just specify the project in cli or config.
i.e. if I want it to be an existing project, I specify it in .fossa.yml; i don't need another flag
There was a problem hiding this comment.
what if it's a custom project though? No github repo?
There was a problem hiding this comment.
That's fine, then it will fail to config and be blank, which will require user to specify
There was a problem hiding this comment.
That's fine, then it will fail to config and be blank, which will require user to specify
There was a problem hiding this comment.
specify where though?
Some notes:
There is a
fossa-corePR: https://github.com/fossas/FOSSA/pull/2339custom(custom) is the fetcher for managed buildsIt doesn't make sense to me that
locatoris a config option (i removed it). Users should not need to know and understand the locator spec, i.e. know where to putgit+and$. We should just infer all of this.I added a
ExistingProjectconfig value that defaults to false. If set to true, then they are adding an existing fossa repo.NOTE: might not be the best way to implement default behavior, as existing users builds will need to be updated