renovatebot / renovate

Home of the Renovate CLI: Cross-platform Dependency Automation by Mend.io
https://mend.io/renovate
GNU Affero General Public License v3.0
17.57k stars 2.31k forks source link

feat: Support XcodeGen #20504

Open coffmark opened 1 year ago

coffmark commented 1 year ago

What would you like Renovate to be able to do?

Add Suprt XcodeGen

XcodeGen automatically generates .xcodeproj files from .yml files.

Library dependencies can be set in the .yml file and installed via SPM.

We would like to support new updates of library versions listed in .yml files with renovate.

How about it ?

Thanks!

If you have any ideas on how this should be implemented, please tell us here.

Implement a built in feature for this.

Is this a feature you are interested in implementing yourself?

Maybe

github-actions[bot] commented 1 year ago

Hi there,

You're asking us to support a new package manager. We need to know some basic information about this package manager first. Please copy/paste the new package manager questionnaire, and fill it out in full.

Once the questionnaire is filled out we'll decide if we want to support this new manager.

Good luck,

The Renovate team

coffmark commented 1 year ago

New package manager questionnaire

Did you read our documentation on adding a package manager?

Basics

Name of package manager

SPM via XcodeGen

What language does this support?

Swift

How popular is this package manager?

Used for .xcodeproj or .xcworkspace project management when developing large scale iOS apps. .xcodeproj or .xcworkspace file is not human readable, so it is generated mechanically from the yml file.

Does this language have other (competing?) package managers?

Developers have several choices


Package File Detection

What type of package files and names does it use?

The default file name is project.yml, but any .yml or .json file will do.

I want .json file is out of the scope for this initial PR. (Because the default file is YML format)

What fileMatch pattern(s) should be used?

I would like to add new key to renvate config file (like xcodegenFileName)

Is it likely that many users would need to extend this pattern for custom file names?

Is the fileMatch pattern likely to get many "false hits" for files that have nothing to do with package management?


Parsing and Extraction

Can package files have "local" links to each other that need to be resolved?

Is there a reason why package files need to be parsed together (in serial) instead of independently?

What format/syntax is the package file in?

I want .json file is out of the scope for this initial PR. (Because the default file is YML format)

How do you suggest parsing the file?

Does the package file structure distinguish between different "types" of dependencies? e.g. production dependencies, development dependencies, etc?

List all the sources/syntaxes of dependencies that can be extracted

XcodeGen Swift Package

Dependencies can be added with a valid Git URL (HTTPS), and can be from any provider (GitHub, GitLab, Bitbucket, etc).

Describe which types of dependencies above are supported and which will be implemented in future

all, but I want minVersion, maxVersion, branch and revision are out of scope for this initial PR.

and local packages are ignored.

Here is sample yml file

packages:
  Yams: # remote package
    url: https://github.com/jpsim/Yams
    from: 2.0.0
  Ink: # remote package
    github: JohnSundell/Ink
    from: 0.5.0
  RxClient: # local package
    path: ../RxClient
  AppFeature: # local package
    path: ../Packages
    group: Domains/AppFeature

Versioning

What versioning scheme does the package file(s) use?

Semantic Versioning

Does this versioning scheme support range constraints, e.g. ^1.0.0 or 1.x?


Lookup

Is a new datasource required? Provide details

Will users need the capability to specify a custom host/registry to look up? Can it be found within the package files, or within other files inside the repository, or would it require Renovate configuration?

Do the package files have any "constraints" on the parent language (e.g. supports only v3.x of Python) or platform (Linux, Windows, etc.) that should be used in the lookup procedure?

No, the packages file format is linked to Xcode version used to generate it, but given the structure has mostly remained the same for a decade, this isn't a major concern

Will users need the ability to configure language or other constraints using Renovate config?

Yes, The default file for XcodeGen is project.yml, but users can dicide for themselves, so we need to specify the file name.


Artifacts

Are lock files or checksum files used? Are they mandatory?

No

If so, what tool and exact commands should be used if updating one or more package versions in a dependency file?

N/A

If applicable, describe how the tool maintains a cache and if it can be controlled via CLI or environment variables? Do you recommend the cache be kept or disabled/ignored?

N/A

If applicable, what command should be used to generate a lock file from scratch if you already have a package file? This will be used for "lock file maintenance"

N/A

Other

Is there anything else to know about this package manager?

No


Sorry for the delay, Looking forward to hearing back from you !

rarkins commented 1 year ago

How popular is this package manager?

Used for .xcodeproj or .xcworkspace project management when developing large scale iOS apps. .xcodeproj or .xcworkspace file is not human readable, so it is generated mechanically from the yml file.

Do these files need to be updated and kept in sync whenever the yml file changes? i.e. update it in the same PR?

Package File Detection

What type of package files and names does it use?

The default file name is project.yml, but any .yml or .json file will do.

We could match against project.yml by default, any other file names would need to be manually configured by the user.

I want .json file is out of the scope for this initial PR. (Because the default file is YML format)

OK

What fileMatch pattern(s) should be used?

I would like to add new key to renvate config file (like xcodegenFileName)

That shouldn't be necessary - we can reuse fileMatch

Is the fileMatch pattern likely to get many "false hits" for files that have nothing to do with package management?

  • Yes

Names like project.yml are likely to be in use for othe reasons

  • majorVersion, from (specify major version)
  • minorVersion (specify minor version)
  • exactVersion, version (fixed version)
  • minVersion
  • maxVersion
  • branch
  • revision (Git SHA)

This probably requires a new Renovate "versioning" to handle these

Versioning

What versioning scheme does the package file(s) use?

Semantic Versioning

See above

Does this versioning scheme support range constraints, e.g. ^1.0.0 or 1.x?

  • [ ] Supports range constraints (e.g ^1.0.0 or 1.x)
  • [x] No

Syntax like from: does in fact mean constraints

Lookup

Is a new datasource required? Provide details

  • [x] Yes, provide details.
  • [ ] No.

It's possible we don't need a new datasource and can just reuse git-refs, github-tags, etc.

coffmark commented 1 year ago

How popular is this package manager? Used for .xcodeproj or .xcworkspace project management when developing large scale iOS apps. .xcodeproj or .xcworkspace file is not human readable, so it is generated mechanically from the yml file.

Do these files need to be updated and kept in sync whenever the yml file changes? i.e. update it in the same PR?

Yes!

Is the fileMatch pattern likely to get many "false hits" for files that have nothing to do with package management? Yes

Names like project.yml are likely to be in use for othe reasons

I see, that's very possible.

majorVersion, from (specify major version) minorVersion (specify minor version) exactVersion, version (fixed version) minVersion maxVersion branch revision (Git SHA)

This probably requires a new Renovate "versioning" to handle these

I see. Thanks !


Thanks for answering some of my questions!

I have found it a bit difficult to make it happen.

I will reconsider, Thanks! :pray:

rarkins commented 1 year ago

This can be left open for people in future to comment or implement