Version the actions

[janhoy]

Now we use apache/infrastructure-actions/pelican@main. Should we start releasing versioned actions so that users are shielded from unintended breaks, and also that they can do controlled upgrades through e.g. dependabot?

[dave2wave]

I concur. I think we can have semver branches as needed with each action taking its own release path to version branches. I would need to double check but that is equivalent to GHA.

[sebbASF]

I agree that there should be versioning as per GHA.

That does not play well with multiple actions in the same repository; they must share the same version branches if the GHA version naming convention is to be followed.

If each action has its own set of branches, then automated checkers such as dependabot are unlikely to work, and it will be harder for projects to use the actions.

[assignUser]

Yeah I think as long as we have one repo for all actions they'd all have to be versioned with the same tag. Well, we could do release branches - uses: apache/infrastructure-actions/pelican@pelican and that would then not require updates from dependabot, because it would always use latest commit.

This does go against recommended practices and as sebb says would prevent the automatic updating of such pins via dependabot, so 'version branches' like pelican-v1 wouldn't work. So adding any breaking changes to the pelican branch would just break the users workflows unannounced vs. in a controlled, visible and fixable way via dependabot PR.

[dave2wave]

What does GitHub do? Each action has its own repository. Maybe we need to discuss that choice along with this choice. Mailing list?

[assignUser]

Github has the 'actions' org with separate repos for each action. I think #asf-ghactions is more targeted then just builds@?

[assignUser]

Just to update this issue with the latest developments:

• dependabot does currently not support per action versioning via tags
  • @gopidesupavan has a fix for this Support for path based tag structure in github_actions module for monorepo structures. dependabot/dependabot-core#11286
• Once the PR is merged/released we can tag versions on a per action basis 🎉

[potiuk]

Indeed :). I am about to switch to all the new features of stash action with the commit hash, but would be nice with a tag so 👀 🤞

[gopidesupavan]

Just to update this issue with the latest developments:

• dependabot does currently not support per action versioning via tags

  • @gopidesupavan has a fix for this Support for path based tag structure in github_actions module for monorepo structures. dependabot/dependabot-core#11286

• Once the PR is merged/released we can tag versions on a per action basis 🎉

Pr approved, hopefully we should be able to see changes in next dependaboat release :)

[gopidesupavan]

Now, regarding the question of tagging: How should we approach it? Should we stick to manual tagging, or consider building an automated process? Currently, we only have a small number of actions, but as we add more, I anticipate it becoming more challenging. What are your thoughts on implementing an automated workflow that assigns tags based on the most recent tag released of action or allows an input to specify the desired tag? Additionally, the workflow could be designed to be triggered manually for simplicity.

[potiuk]

This is a very good point to discuss :).

I think it would be great to have some (but very simple) automation of "produce a changelog + tag". Initially that could be as simple as agreeing a convention.

My proposal is:

• CHANGELOG.rst in the root folder of the action
• <ACTION_MAME>/vX - as (fast-forwardable) branch name for those who want to upgrade automatically
• <ACTION_NAME>/vX-Y tag

And just documenting the "release process" initially - and possibly automate a bit some pieces in it - write simple scripts for some parts of it.

I don't expect we have "huge" amount of actions and especially not "huge" amount of changes.

My wild guess is that most of the actions will get some initial influx of changes/fixes after they are released (like the stash action) and then rather slow set of small features/fixes, and semi-regular (every couple of months) upgrades due to dependency upgrades (mostly dependabot driven hopefully).

The "release process" in this case should be as simple as:

• update changelog (we can semi-automatically produce list of commits messages relevant since last release)
• push a tag (signed to track provenance of who pushed it !)
• possibly produce a release in "releases" of the project (that also can be a very simple script that produces release information from the CHANGELOG.rst)

I think it's worth to keep both CHANGELOG.rst (then all history of releases/changelogs) is also kept in Git - independently from GitHub, + using GitHub releases (those are nice and easy to discover in the "Releases" tab of the GitHub repo).

Also I think more important is the process of making the release and some protections - who initiates it and who can create/move branches and tags and whether we want to have some formalisation of it (i.e. voting?).

I would think that's a good idea would be that a PR with release / changelog need to have at least 2 +1s from other collaborators of the repo - reviewing the relevant commits. This would be a nice way to "legitimate" the release tags. We expect people in ASF to "trust" those releases in their projects - without commit hash specified in their repos, and since we likely (eventually) want to invite more people to contribute and possibly be able to approve and merge changes to diverse set of actions, some protection on what is "official ASF release" of those actions is a good thing to have.

I belive if se specifty */v* branches as "protected" branches and add +2 votes as requirement there, we should be able to control it - but not sure how it would work with moving protected branches with fast-forward - we should test it.

Also we can add tag protection https://docs.github.com/en/enterprise-server@3.15/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules#adding-tag-protection-rules - which means that only admin/maintainers will be able to add /v tags to the repo - which might be a good idea - especially if we will (hopefully) be adding more people to possibly be able to review and merge actions.

[assignUser]

#95 will be helpful for automatic generation of both versions and change logs :)

Otherwise I agree especially with using branch protection! We'll have to see how we can work with the tags etc.

[potiuk]

https://github.com/apache/infrastructure-actions/discussions/95 will be helpful for automatic generation of both versions and change logs :)

Indeed!

[gopidesupavan]

Yes Jarek those are really valid points. We should add release process.