search

eclipse-kuksa / kuksa-actions

Reusable Github actions and workflows used in the Eclipse KUKSA project
Apache License 2.0
1 stars 2 forks source link

Adding check_push_rights #1

Closed erikbosch closed 11 months ago

erikbosch commented 11 months ago

Currently this workflow exists in both kuksa.val and kuksa.val.feeders. As we are to split repos we might get even more, and then it is good to have a common reusable location for it

Related to:

https://github.com/eclipse/kuksa.val/pull/680 https://github.com/eclipse/kuksa.val.feeders/pull/145

Those two PRs needs to be updated when this PR is merged. We can also discuss release pattern for this repo, do we want to tag after every merged (significant) PR, or just when major backward incompatible changes are introduced. In this case, for now, users could easily use main as version identifier so no urgent need to tag.

SebastianSchildt commented 11 months ago

I would say, we should just use tagged version and always tag, when something "significant/incompatible" changes in any of the actions hosted here. If just fixing a bug in one, it might be ok, to just retag.

In any case the only disadvantage is, as any change in action demands a new tag, numbers might go up fast. But it will be quite robust, we can change "everything" here, without disturbing workflows

erikbosch commented 11 months ago

I would say, we should just use tagged version and always tag, when something "significant/incompatible" changes in any of the actions hosted here. If just fixing a bug in one, it might be ok, to just retag.

In any case the only disadvantage is, as any change in action demands a new tag, numbers might go up fast. But it will be quite robust, we can change "everything" here, without disturbing workflows

We could actually use a "double tag" mechanism, some other actions use that. Like have both a major tag X and a minor X.Y and only increase major in case of backward incompatible changes. Then users can specify minor version if they want to stick to a specific version, but major if they accept changes that does not affect backward compatibility

That way users can decide if they just want the lates

erikbosch commented 11 months ago

PR refactored based on discussion. Seems to work as expected for kuksa.val and kuksa.val.feeders. @SebastianSchildt -feel free review again. Suggested way forward: