semantic-release configuration

[martinmigasiewicz-tomtom]

We are using semantic-release and have as well some custom types. It would be great if the action could as well read (e.g., .releaserc.json) from the project and use the same rules/configuration.

[kevgo]

We need that as well. Background: we use this action on hundreds of repos. Our Ops team sets up this action with a centrally managed base configuration for all repos. Individual repos should be able to override individual settings if needed.

[amannn]

Thanks for chiming in! @zepatrik just provided a first implementation in #193.

I have some open questions currently that I think we should resolve before moving forward:

• Is there any reasonable way to share configuration across repositories as @kevgo has mentioned it above?
• Should we try to use config from another tool like semantic-release? The problem here is that we support configuration that the other tool doesn't and vice versa.
• What is the benefit of using an external configuration file instead of configuring the action in the workflow file?
• How should configuration be handled if it's provided both via the config and the workflow file? I'd vote to prioritise config from the workflow file and overwrite options as relevant (i.e. not merging them, e.g. concatenating lists).
• What is a good place and name for the config file?

Generally it's helpful at this stage to collect use cases to make sure we can cover everything in case we introduce this.

[zepatrik]

Is there any reasonable way to share configuration across repositories as @kevgo has mentioned it above?

In our case we use a repository that has a bunch of automation to sync default workflows and other files across the organization, especially this workflow: https://github.com/ory/meta/blob/44cf1a812de176ad5c6923a9cae7edc5195ced0d/templates/repository/common/.github/workflows/conventional_commits.yml

What is the benefit of using an external configuration file instead of configuring the action in the workflow file?

The problem with that is that basically all config values are the same across the whole organization, but not the scopes. They should be configurable per repository. Until a few weeks back we used https://github.com/zeke/semantic-pull-requests which did support that workflow, but that service does not work anymore.

Should we try to use config from another tool like semantic-release? The problem here is that we support configuration that the other tool doesn't and vice versa.

If that works, sure. Open for suggestions.

How should configuration be handled if it's provided both via the config and the workflow file?

In our case the base is the workflow file, and the separate config is the override. But we could make both work for the use-case.

What is a good place and name for the config file?

There is already a lot of dot-files in the repository root. https://github.com/zeke/semantic-pull-requests had a semantic.yml file under .github, which makes sense because it is CI related.

[amannn]

Thanks for sharing the details and your proposed solutions @zepatrik!

I'm actually wondering if there's a way to already achieve this and if we're in a better position if we don't move this into the core of this action.

E.g. for the use case of sharing a lot of configuration across a multitude of repositories, I could image a good way would be to create a composite action that pre-configures this action with everything that needs to be shared and offers inputs for what needs to be overridden. I haven't tried this out, but if it works that way, you'd be able to reference your composite action in all the repositories and only provide the configuration you need to customise per repository (e.g. scopes). That way you could avoid syncing the configuration and you have a single place where you can update it.

In regards to the config file, I think you could define such a file for yourself if you really need it and provide its values as dynamic inputs to this action (example). Another use case I could think of is reading configuration from a remote URL, this would work with the dynamic inputs too.

So potentially there's already a solution to this that offers much more flexibility than what we could offer if we support this in the core of this action.

[zepatrik]

I could image a good way would be to create a composite action that pre-configures this action with everything that needs to be shared and offers inputs for what needs to be overridden.

Yes, actually @kevgo already started to implement such an action: ory/ci#94