Skip to content

Publish and Prerelease from multiple branches (input desired) #423

Closed
Closed
Publish and Prerelease from multiple branches (input desired)#423
Labels
featureA new feature or a feature requestfixed-in-v8Issues which will be or are fixed in PSR v8

Description

@jacksbox
jacksbox
opened on Mar 7, 2022

Description

Related to this Issue and PR from me regarding prereleases:
#386
#413

With the (hopefully soon) new prerelease option, it would be nice to have the option to publish from multiple branches with different options.

Use cases

This would enable flows like:

Branch: master -> publish normal new version
Branch: dev -> publish new beta prerelease
Branch: feature/* -> publish new alpha prerelease

Possible implementation

This would change how the branch configuration option works - or possible remove it - as we than would not check out a branch on the publish command, but would analyse what to exactly do based on the currently checked out branch.

PS: Another possible option to handle this, could be a dedicated prerelease command which can be called from the ci pipeline directly, which than would operate on the current branch...

Would love to get some input!

Activity

  1. jacksbox
    added
    featureA new feature or a feature request
    on Mar 7, 2022

  2. bernardcooke53 commented on Mar 28, 2022

    @bernardcooke53
    bernardcooke53
    on Mar 28, 2022
    Contributor

    Hi @jacksbox, @williamluke4 & @danth

    I've been using the Node semantic-release for a while & in the process of converting to this to eliminate the need for Node installation on some Jenkins agents, and was looking to see if this was a feature today/came across this issue. I use pyproject.toml for configuration so 🙏 please guide me if anything doesn't fit for setup.cfg, my level of understanding is "read the docs" for the latter.
    If it was free-reign I think I'd look to implement the following:

    Proposals

    1. Create a new sub-table configuration option, something like

    [tool.semantic_release.branches]
"branch regex" = <per-branch config dict>
# e.g.
main = true # always release
"^dev-?.*" = {prerelease = true, prerelease_tag = "alpha"}

    I believe it's possible to create the same kind of structure in setup.cfg:

    [tool:semantic_release.branches]
"^dev-*$"=
    =prerelease = true
    =prerelease_tag = "alpha"

    but admittedly haven't really tested yet.

    This kind've follows the options available in the Node semantic-release configuration, and would allow a per-branch pattern configuration to hook into.

    I had some ideas around defining keys such as force_major, force_minor and force_patch as boolean flags, which would help with multibranch CI pipelines when a user wants to associate a specific meaning with their branch naming conventions.
    I also wonder if there's value in capturing groups from the branch regex for use in the config too - food for thought 🤔 ?

    I think this will hook into the recent pre-release functionality pretty well as the recent inclusion of pre-release functionality in your PR, since (if I understood correctly) that relies on setting a flag True/False for whether we are or aren't doing a pre-release - it should be doable to grab that from the per-branch config structure above, provided we can match on branch name.

    A question I still have is what the default should look like - I suggest a default which has the same effect as

    [tool.semantic_release.branches]
master = true

    but the specifics will depend on what options are allowed in that per-branch configuration. It could go as granular as allowing most other configuration settings (e.g. upload_to_repository, upload_to_release etc) to be done on a per-branch-pattern basis, or kept pretty tight in the first instance. Ultimately though I do think that being able to set most keys under Distribution and maybe Commits (at least commit message?) would be useful functionality.

    2. Deprecate the branch configuration key

    In favour of using the sub-table as outlined above.

    3. Change the default behaviour around branches

    Instead of checking the branch out from the configuration's branch key, semantic-release should check the current branch that the user is on in their repository, and if it doesn't match any configuration then should probably just print a message and exit gracefully.

    Implementation

    I think 1 and 2 are do-able without introducing any breaking changes, however the change to the default behaviour 3 will be what really makes the multibranching config come alive. All the while semantic-release is limited to checking out a target branch and then releasing, I guess the table for multibranching would have somewhat limited value.

    What do you think of this? If no-one is looking at it yet I should have some space in the next couple of weeks to start drafting a PR, but better to get your thoughts first 🙂.

    EDIT: removed the suggestion for "branch regex" = false, would be unneeded compared to simply not configuring semantic-release to run a release on that branch pattern.

  3. bernardcooke53 commented on Mar 31, 2022

    @bernardcooke53
    bernardcooke53
    on Mar 31, 2022
    Contributor

    @relekang hi, came to check on this and realised I didn't include you in the set of tags- sorry about that! I'd love to get your thoughts on the above, if that's a direction python-semantic-release could go in

  4. github-actions commented on Apr 22, 2022

    @github-actions
    github-actionsbot
    on Apr 22, 2022

    This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

  5. github-actions
    added
    help-wantedExtra attention is required
    on Apr 22, 2022
  6. github-actions
    removed
    help-wantedExtra attention is required
    on Oct 23, 2022

  7. github-actions commented on Nov 13, 2022

    @github-actions
    github-actionsbot
    on Nov 13, 2022

    This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.

  8. github-actions
    added
    help-wantedExtra attention is required
    and removed
    help-wantedExtra attention is required
    on Nov 13, 2022

  9. gpiotti commented on Jan 3, 2023

    @gpiotti
    gpiotti
    on Jan 3, 2023

    Hi I'm also interested in this features, I was thinking on just add branch to the semantic-release command as a paremeter, but not sure if the inner-workings allow this
    something like:
    semantic-release --prerelease branch=develop
    will be used if for example the merge is to the "develop" branch
    if the merge is to the "master" branch it could be
    semantic-release branch=master

  10. github-actions commented on Mar 26, 2024

    @github-actions
    github-actionsbot
    on Mar 26, 2024 – with GitHub Actions

    This issue is stale because it has not been confirmed or planned by the maintainers and has been open 90 days with no recent activity. It will be closed in 7 days, if no further activity occurs. Thank you for your contributions.

  11. github-actions
    added
    stale
    on Mar 26, 2024
  12. codejedi365
    added
    fixed-in-v8Issues which will be or are fixed in PSR v8
    and removed
    stale
    on Mar 27, 2024

  13. codejedi365 commented on Mar 27, 2024

    @codejedi365
    codejedi365
    on Mar 27, 2024
    Contributor

    Completed in v8 release.

  14. codejedi365
    closed this as completedon Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureA new feature or a feature requestfixed-in-v8Issues which will be or are fixed in PSR v8

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions