Add command to create a release group release #1409

JeffreyHuynh1 · 2024-04-15T02:21:24Z

Overview

The CLI should offer a way to create release group release from the command line

Acceptance criteria

There is a way to create a release group release from the CLI.

Testing plan

example .fossa.yml:

releaseGroup:
  title: example-title
  release: example-release-title
  releaseGroupProjects:
    - projectLocator: custom+1/git@github.com/example
      projectRevision: 12345 
      projectBranch: main

Create a release group release:

fossa release-group create-release --title example-title --release example-release-title --project-locator custom+1/git@github.com/example --project-revision 12345 --project-branch main
fossa release-group create-release -c /path/to/.fossa.yml/

Risks

Metrics

References

ANE-1628

Checklist

I added tests for this PR's change (or explained in the PR description why tests don't make sense).
If this PR introduced a user-visible change, I added documentation into docs/.
If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.

spatten

The code is looking good.

I'd like to see a more thorough test plan, though. The test plan only tests with one project being added to the release group and does not test any of the failure cases. I.e. it would be good to test what happens if you try to create a release group while missing the --project-branch flag. It would also be good to specifically test with multiple projects being added.

We should also test the delete command that was added in this PR

spatten · 2024-04-17T17:54:27Z

docs/references/subcommands/release-group/create-release.md

+## Example
+
+```bash
+fossa release-group create-release --title example-release-group --release example-release --project-locator custom+1/example --project-revision 1234 --project-branch main --project-locator custom+1/example2 --project-revision 5678 --project-branch main 


I think we should explicitly document that you can have mulitple groups of project-locator, project-revision and project-branch args, and that the sets of args are grouped together based on their order.

I was able to create a new release group with a branch that did not exist. Is this a bug or is it expected?

fossa release-group create-release --title "Test release group" --release example-release-title-3 --project-locator custom+24987/2779 --project-revision 1625011087 --project-branch master --project-locator custom+24987/4361-repro --project-revision 1657063285 --project-branch does-not-exist

This successfully created the release. You can see it here on the scottpatten.ca org: https://app.fossa.com/projects/group/1396/projects

When I click through on the "4361-repro" project, I see a "Branch does not exist" error

I was able to create a new release group with a branch that did not exist. Is this a bug or is it expected?

This is expected behavior, I brought it up with Core and filed a ticket: https://fossa.atlassian.net/browse/CORE-3155

I think we should explicitly document that you can have multiple groups of project-locator, project-revision and project-branch args, and that the sets of args are grouped together based on their order.

Good point, I can see this being confusing to readers. There documentation on how those 3 flags are grouped together here and documentation on providing multiple instances of these flags here. It's all kind of spread apart so I can write a consolidate blurb as well as adding context on the grouping order.

whoa.... all those locator-specific args are required? is there no way to match strings and just create a release called example-release within an existing example-release-group? (I realize I'm probably oversimplifying) cc @vishal-thenge

It seems like if fossa analyze --release-group-name 'MY_RG' --release-group-release 'MY_RELEASE' is possible, we should also decouple creating releases and release groups from project locators, revisions, and branches.

@JeffreyHuynh1 makes sense, although conceptually I can't understand why releases are inherently tied to projects instead of standalone containers. I guess that's why empty releases can't exist, which CORE-3189 was proposed to fix.

@ryanlink 100% . When Core has implemented a way to support empty releases, we will be able to remove the requirement of having a project added to a release in the CLI.

@ryanlink by "match strings" do you mean infer the revision and project name that the user wants to add to the release group?
At the very least we have to offer a way for a user to create a release group with all of these flags, but maybe there's a way we can make it easier for users who have analyzed a project recently.
I'm not sure if this is possible or if we want to do this, but what about a flag like --most-recently-analyzed-revision that pulls the local data from the last time fossa analyze was run to populate --revision and --locator. Would that solve what you're looking for?

@zlav

do you mean infer the revision and project name that the user wants to add to the release group?

no, I meant in the case where they just want to create a new release version within an RG for subsequent use in a fossa analyze command... but wasn't thinking about the fact that you can't currently create an empty release in the core app.

however, this does support Nexthink's request for fossa analyze --release-group-name XXX -release-group-release ZZZ to create the release ZZZ within the RG if it doesn't already exist.

@JeffreyHuynh1 copying here from Slack - can we add this reference to the docs?

You can run fossa analyze --json and get the data you need https://github.com/fossas/fossa-cli/blob/master/docs/references/subcommands/analyze.md#printing-project-metadata (project locator, etc.)

and this may be out of scope for this PR, but echoing @vishal-thenge 's request:

if we only have a projectLocator; but not: projectRevision & projectBranch to fossa release-group; can we add support to default them to the i) default branch & ii) latest revision ?

JeffreyHuynh1 · 2024-04-17T23:49:30Z

I'd like to see a more thorough test plan, though. The test plan only tests with one project being added to the release group and does not test any of the failure cases. I.e. it would be good to test what happens if you try to create a release group while missing the --project-branch flag. It would also be good to specifically test with multiple projects being added.

There's a test to see if the release group exists before creating the release: https://github.com/fossas/fossa-cli/pull/1409/files#diff-a6883bdfe80cf7750f86281dce66c203f54d3086a7bce60cb2fe46fb7a5c4019R45
It seems like you're suggesting that we incorporate more tests at the parsing level when constructing the CreateRelease config. Would it be something similar to: https://github.com/fossas/fossa-cli/blob/master/test/App/Fossa/Config/ReleaseGroup/CreateSpec.hs
- Or are you suggesting a more detailed manual testing plan?

We should also test the delete command that was added in this PR

The delete command was added in prior a PR. We have tests for it here: https://github.com/fossas/fossa-cli/blob/master/test/App/Fossa/ReleaseGroup/DeleteSpec.hs

spatten · 2024-04-22T21:24:25Z

  * Or are you suggesting a more detailed manual testing plan?

I was suggesting a more detailed manual testing plan. Sorry for the confusion :)

spatten

This all looks good to me!

I added one optional comment on the docs, but nothing blocking

docs/references/subcommands/release-group.md

JeffreyHuynh1 added 4 commits April 14, 2024 19:13

Add command to create a release group release

b7fcf05

udpate create release group test

9369ac2

update changelog

b4e4111

format spectrometer.cabal

3d01053

JeffreyHuynh1 marked this pull request as ready for review April 15, 2024 16:44

JeffreyHuynh1 requested a review from a team as a code owner April 15, 2024 16:44

JeffreyHuynh1 requested a review from spatten April 15, 2024 16:45

spatten reviewed Apr 17, 2024

View reviewed changes

JeffreyHuynh1 added 3 commits April 18, 2024 15:37

update docs

47c1a71

merge changes from master

641cb83

update release-group.md

0b8df56

JeffreyHuynh1 requested a review from spatten April 18, 2024 22:48

spatten approved these changes Apr 22, 2024

View reviewed changes

docs/references/subcommands/release-group.md Outdated Show resolved Hide resolved

JeffreyHuynh1 added 3 commits April 23, 2024 09:08

Merge branch 'master' into create-release-group-release

2afc1c0

address pr comments

fa89d66

merge changes from main

14e8995

JeffreyHuynh1 merged commit 0479bae into master Apr 25, 2024
16 checks passed

JeffreyHuynh1 deleted the create-release-group-release branch April 25, 2024 19:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add command to create a release group release #1409

Add command to create a release group release #1409

JeffreyHuynh1 commented Apr 15, 2024 •

edited

Loading

spatten left a comment

spatten Apr 17, 2024

spatten Apr 17, 2024

JeffreyHuynh1 Apr 17, 2024

JeffreyHuynh1 Apr 18, 2024

ryanlink Apr 19, 2024 •

edited

Loading

ryanlink Apr 19, 2024

JeffreyHuynh1 Apr 19, 2024

zlav Apr 19, 2024

ryanlink Apr 19, 2024 •

edited

Loading

ryanlink Apr 19, 2024

JeffreyHuynh1 commented Apr 17, 2024 •

edited

Loading

spatten commented Apr 22, 2024

spatten left a comment

Add command to create a release group release #1409

Add command to create a release group release #1409

Conversation

JeffreyHuynh1 commented Apr 15, 2024 • edited Loading

Overview

Acceptance criteria

Testing plan

Risks

Metrics

References

Checklist

spatten left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryanlink Apr 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryanlink Apr 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JeffreyHuynh1 commented Apr 17, 2024 • edited Loading

spatten commented Apr 22, 2024

spatten left a comment

Choose a reason for hiding this comment

JeffreyHuynh1 commented Apr 15, 2024 •

edited

Loading

ryanlink Apr 19, 2024 •

edited

Loading

ryanlink Apr 19, 2024 •

edited

Loading

JeffreyHuynh1 commented Apr 17, 2024 •

edited

Loading