Skip to content

[AE-181] Add check-release-version.yml workflow #28

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.

Sign up for GitHub

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

Closed
wants to merge 4 commits into from
Closed

[AE-181] Add check-release-version.yml workflow #28

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
63c07ba
Add check-release-version workflow
aliphys Nov 9, 2023
64d2ef0
correct library.properties version
aliphys Nov 9, 2023
748693f
ci: add error directly to echo message
aliphys Nov 17, 2023
6f866f9
Merge branch 'main' into aliphys/addReleaseVersionCheck
aliphys Nov 17, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions .github/workflows/check-release-version.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# Workflow to check if the version in library.properties matches the latest release
# If it does not, deletes the release and the corresponding tag
name: Get Latest Release

on:
release:
types:
- published

jobs:
get_release:
runs-on: ubuntu-latest

steps:
# Step 1: Checkout the repository code
- name: Checkout code
uses: actions/checkout@v2
Comment on lines +15 to +17
Copy link
Contributor

Choose a reason for hiding this comment

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

The repository should be checked out at the tagged version. Even though it is common to tag at the revision at the current tip of the default branch, there is no requirement for doing so.

It can be useful to tag a prior revision in the case where a release is needed, but some of the recent work is not yet ready for release. The workflow should accommodate that possibility.

This can be done by moving the checkout step to after the step that gets the tag, then passing the tag to the ref input of the actions/checkout action.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So you propose that tagging is performed manually by the maintainers?

Copy link
Contributor

Choose a reason for hiding this comment

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

No, not propose. That is simply the current practice in Arduino's library repositories and no change to that practice had been proposed at the time I wrote this.

It was only later that an alternative procedure, by which the tags and GitHub Releases would be created automatically was proposed (#28 (comment)).


# Step 2: Retrieve the latest release from the GitHub API
- name: Get latest release
id: get_latest_release
run: |
set -e
response=$(curl --silent "https://api.github.com/repos/${{ github.repository }}/releases/latest")
echo "Response: $response"
latest_release=$(echo "$response" | jq -r .tag_name)
echo "Latest release: $latest_release"
echo "::set-output name=release::$latest_release"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

# Step 3: Check the version in the library.properties file and compare it with the latest release
- name: Check version in library.properties
id: compare_version
run: |
version=$(cat library.properties | grep "version" | cut -d'=' -f2)
echo "Version in library.properties: $version"
echo "Version in release: ${{ steps.get_latest_release.outputs.release }}"
if [ "$version" == "${{ steps.get_latest_release.outputs.release }}" ]; then
echo "Versions match!"
else
echo "Versions don't match."
fi
echo "::set-output name=version::$version"

# Step 4: Delete the release if the versions don't match
- name: Delete release if failed
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess the idea is that you will correct library.properties and then push the deleted tag again?

Moving a tag after it was pushed to a public repository is considered a bad practice that can cause problems:

https://git-scm.com/docs/git-tag#_on_re_tagging

I know that Arduino developers already sometimes re-tag, but formalizing the bad practice in a workflow that is bound to propagate to many projects is another story.

The correct approach is to push a new tag with a correct library.properties (e.g., if the 1.1.0 tag was bad, then bump the version field to 1.1.1 and then push a 1.1.1 tag).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I know that for the core, tagged versions (but not released) are avaliable via the IDE. Hence the reason the tag must be deleted, although I agree this is not an ideal approach.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This tag dependant behaviour is mentioned here:

https://github.com/arduino/library-registry/blob/0fe11ac0074785431be01f2bf6362b4b2ccc8224/FAQ.md?plain=1#L56

Copy link
Contributor

Choose a reason for hiding this comment

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

tagged versions (but not released) are avaliable via the IDE. Hence the reason the tag must be deleted, although I agree this is not an ideal approach.

Note the second step described at the link you shared:

  1. checks whether those tags meet the requirements for addition to the index

The Arduino Library Manager engine will reject any tag where the value of the version field of library.properties at the tag is the same as a previously indexed release of the library.

So this means there is no need to delete tags for the sake of Library Manager. The tags where the library maintainer forgot to update the library.properties file before tagging will simply be ignored by the engine.

if: ${{ steps.compare_version.outputs.version != steps.get_latest_release.outputs.release }}
uses: dev-drprasad/[email protected]
with:
tag_name: ${{ steps.get_latest_release.outputs.release }}
github_token: ${{ secrets.GITHUB_TOKEN }}
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

# Step 5: Fail the workflow if the versions don't match
- name: Fail workflow if failed
if: ${{ steps.compare_version.outputs.version != steps.get_latest_release.outputs.release }}
run: |
echo "::error::Versions don't match. Failing the workflow."
exit 1