-
Notifications
You must be signed in to change notification settings - Fork 6
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
Conversation
There was a problem hiding this 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?
|
||
# updates the eventual core library version in the version catalog | ||
sed -i 's#^edc = .*#edc = "${{ inputs.version }}"#g' gradle/libs.versions.toml | ||
|
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
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
yes, once this is merged I will create the workflows in the repos. |
this should be easily doable by restricting the trigger to the on:
pull_request:
branches:
- release
types:
- closed
workflow_dispatch: |
* build: add technology repo release workflows * pr remarks
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
release-component
workflow, that's has not been used in the last monthsLinked 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.