Skip to content
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

Manifest release configuration not compatible with Monorepo that is a node project with a rust workspace #2207

Open
nrodriguez-chub opened this issue Jan 30, 2024 · 3 comments · May be fixed by #2211
Assignees
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@nrodriguez-chub
Copy link

nrodriguez-chub commented Jan 30, 2024

  1. Is this a client library issue or a product issue?
    Client library

  2. Did someone already solve this?
    Nope

  3. Do you have a support contract?
    Nope

If the support paths suggested above still do not result in a resolution, please provide the following details.

Environment details

  • OS: Unix / Linux
  • Node.js version: v20.9.0
  • npm version: 10.1.0
  • release-please version: 4

Steps to reproduce

  1. Create a Serverless project with a Rust workspace. Given how serverless works, it is established as a Node project, that acts as a wrapper for the Rust workspace.
    Ideally, what I want to achieve is that no matter the file that is modified in the repo, all components should bump their release to the same next value.
    Currently, I was able to achieve the following:
  • if any file on the rust packages is touched, version is bumped on all the rust modules
  • if any file is touched outside the rust packages, version is bumped only on the node project

I use a manifest release, combined with the plugins rust-workspace and linked-versions, as stated in the docs.
Is there a way to tell release-please that the root project should be treated the same way as the others? thanks.

Example structure of the project (simplified):

.
├── README.md
├── serverless.yml
├── .release-please-manifest.json
├── node_modules
├── package-lock.json
├── package.json
├── release-please-config.json
├── Cargo.lock
├── Cargo.toml
├── bots
 │  ├── pck-a
 │   │   ├── Cargo.toml
 │   │   ├── serverless.yml
 │   │   └── src
 │  ├── pck-b
 │   │   ├── Cargo.toml
 │   │   ├── serverless.yml
 │   │   └── src

release-please-config.json file:

{
    "include-component-in-tag": false,
    "packages": {
        ".": {
            "release-type": "node",
            "component": "root"
        },
        "bots/pck-a": {
            "release-type": "rust",
            "component": "pck_a"
        },
        "bots/pck-b": {
            "release-type": "rust",
            "component": "pck_b"
        },
    },
    "plugins": [
        {
            "type": "cargo-workspace",
            "merge": false
        },
        {
            "type": "linked-versions",
            "groupName": "group-all",
            "components": [
                "root",
                "pck_a",
                "pck_b"
            ]
        }
    ]
}

The file .release-please-manifest.json content looks like this:
{
".": "2.2.0",
"bots/pck-a": "2.2.0",
"bots/pck-b": "2.2.0"
}

Update:

I would be ok with not upgrading the node package.json version, I don't actually need that, but what I DO need is that whenever any file in the project has a change, all the rust packages bump their version. I tried using extra-files for this, but failed miserably :D

@nrodriguez-chub nrodriguez-chub added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Jan 30, 2024
@nrodriguez-chub
Copy link
Author

nrodriguez-chub commented Jan 31, 2024

Well, did more research, and realised that this config will never work with the current codebase, given having include-component-in-tag=false and using linked-versions plugin configured has an open PR:
#1749
Merging that PR should fix my case.

@nrodriguez-chub
Copy link
Author

I created a new fork and corresponding PR to solve the issue, here: #2208
I had to do it as the PR was too outdated with main branch

@nrodriguez-chub
Copy link
Author

Given I created the fork with the company I work for user, I preferred to close it and create a new one with my personal account, so the acceptance of google policy is way easier and faster:
#2211

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants