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

build: add technology repo release workflows #135

Merged
merged 2 commits into from
Aug 14, 2024
Merged

Conversation

ndr-brt
Copy link
Member

@ndr-brt ndr-brt commented Aug 13, 2024

What this PR changes/adds

Adds workflows to be called by the Technology- repos on release.
ref. eclipse-edc/docs#189

Why it does that

Briefly state why the change was necessary.

Further notes

  • removed the release-component workflow, that's has not been used in the last months

Linked Issue(s)

Closes # <-- insert Issue number if one exists

Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

@ndr-brt ndr-brt added the enhancement New feature or request label Aug 13, 2024
Copy link
Member

@paullatzelsperger paullatzelsperger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool stuff! Am I correct in assuming that every tech repo will have to have a prepare-release.yaml and publish-release.yaml workflow, which are triggered manually, or upon PR merging respectively, that in turn call up these WF's here?

.github/workflows/technology-prepare-release.yml Outdated Show resolved Hide resolved

# updates the eventual core library version in the version catalog
sed -i 's#^edc = .*#edc = "${{ inputs.version }}"#g' gradle/libs.versions.toml

Copy link
Member

@paullatzelsperger paullatzelsperger Aug 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically, we'd also have to update the version in the DEPENDENCIES file, otherwise we'd be releasing artefacts with wrong dependencies listed.

Since we have to do that, i don't know of a reliable regex for DEPENDENCIES, how about simply parsing the "old" version from gradle.properties like so:

existingVersion=$(grep "version" gradle.properties  | awk -F= '{print $2}')

and then all files could be sed-ed in one go:

grep -rlz "$existingVersion" . --exclude=\*.{sh,bin} | xargs sed -i "s/$existingVersion/${{ inputs.version }}/g"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the nice thing about this new process is that the preparation phase will create a PR that will need to be merged manually, so in that one all the checks should run, dependencies one included, at that point the committer will need to fix everything (and eventually, for a bugfix, cherry-picking the fix commits) before merging it and trigger the release

.github/workflows/technology-prepare-release.yml Outdated Show resolved Hide resolved
.github/workflows/technology-release.yml Outdated Show resolved Hide resolved
@ndr-brt
Copy link
Member Author

ndr-brt commented Aug 14, 2024

cool stuff! Am I correct in assuming that every tech repo will have to have a prepare-release.yaml and publish-release.yaml workflow, which are triggered manually, or upon PR merging respectively, that in turn call up these WF's here?

yes, once this is merged I will create the workflows in the repos.
just for nitpicking: prepare could be manual, but the actual release will automatically start once the PR with the release/bugifx is merged on the correct branch.
EDIT: maybe we could have the proper release automatically triggering the worflow after merge while the bugfix could be manual to permit cherry-picks and backports to happen separately.

@paullatzelsperger
Copy link
Member

paullatzelsperger commented Aug 14, 2024

EDIT: maybe we could have the proper release automatically triggering the worflow after merge while the bugfix could be manual to permit cherry-picks and backports to happen separately.

this should be easily doable by restricting the trigger to the release/ branch prefix:

on:
  pull_request:
    branches:
      - release
    types:
      - closed
  workflow_dispatch:

@ndr-brt ndr-brt merged commit f47588e into main Aug 14, 2024
4 checks passed
@ndr-brt ndr-brt deleted the technology-release-wf branch August 14, 2024 12:06
ndr-brt added a commit that referenced this pull request Aug 14, 2024
* build: add technology repo release workflows

* pr remarks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants