YahnisElsts / plugin-update-checker

A custom update checker for WordPress plugins. Useful if you don't want to host your project in the official WP repository, but would still like it to support automatic updates. Despite the name, it also works with themes.
MIT License
2.21k stars 403 forks source link

Release assets fallback to first/default .zip even if releaseassets regex is applied. #529

Open melcarthus opened 1 year ago

melcarthus commented 1 year ago

When using the gitlab-ci.yml file of mine I can succesfully build releases for my wordpress theme. Each release that I build comes with 5 assets 1 of them being a build package containing no source files (no src/scss/gulp files etc...) that i want to use in the plugin update checker.

I'm calling the enableReleaseAssets and using the name of the zip, 'landingpages.zip' But it falls back to the full release asset.

I read in the documentation about the 3 ways to get an update -tag -release -stablebranche

I want to add tags to my release, but I also want to use the custom release assets.

How am I supposed to setup the update checker so it uses the correct release asset and not just the first one it encounters.

I looks like its not working but maybe because i am using tags in my release the custom release assets are ignored?

I'm kind of stuck and would like some help on this.

The asset link I want to use

https://gitlab.com/api/v4/projects/projectid/packages/generic/landingpages/v4.4.6/landingpages.zip

The (first) asset link it is always pointing to regardless of my enableReleaseAssets calback.

https://gitlab.com/user/landingpages/-/archive/v4.4.6/landingpages-v4.4.6.zip)

Release assets

image

gitlab-ci.yml

stages:
  - upload
  - release

# Refer to: https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs/examples/release-assets-as-generic-package/
# PACKAGE_VERSION=$(sed -nE 's/^Version: ([0-9.]+)/\1/p' style.css)
upload:
  stage: upload
  image: curlimages/curl:latest
  rules:
    - if: $CI_COMMIT_TAG
  artifacts:
      name: "${CI_PROJECT_NAME}"
      paths:
        - ${CI_PROJECT_NAME}.zip
      expire_in: 1 day
  script:
    - |
      PACKAGE_VERSION="${CI_COMMIT_TAG}"
      PACKAGE_REGISTRY_URL="${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/${CI_PROJECT_NAME}/${PACKAGE_VERSION}"
      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file ${CI_PROJECT_NAME}.zip ${PACKAGE_REGISTRY_URL}/${CI_PROJECT_NAME}.zip
      echo 'Package uploaded!'
# Refer to: https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs#using-this-tool-in-gitlab-ci

release:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - |
      PACKAGE_VERSION="${CI_COMMIT_TAG}"
      PACKAGE_REGISTRY_URL="${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/${CI_PROJECT_NAME}/${PACKAGE_VERSION}"      
      release-cli create \
        --name "Release $CI_COMMIT_TAG" \
        --description "Release of $CI_COMMIT_TAG from $CI_PROJECT_NAME" \
        --tag-name "$CI_COMMIT_TAG" \
        --assets-link "{\"name\":\"${CI_PROJECT_NAME}.zip\",\"url\":\"${PACKAGE_REGISTRY_URL}/${CI_PROJECT_NAME}.zip\"}"
    - |
      echo "Created release of ${CI_PROJECT_NAME}!"
YahnisElsts commented 1 year ago

One possible issue is regex syntax. PUC uses the provided regex as-is, without adding any delimiters or flags. So if your regex is literally 'landingpages.zip', that's not going to work because without delimiters that's not a valid PCRE regex pattern. Try changing it to something like '/landingpages.zip/'.

melcarthus commented 1 year ago

Just changed it to a better pattern. Stil points to the main release zip.

YahnisElsts commented 1 year ago

That part of the code doesn't have enough logging to effectively debug it remotely. Would you perhaps be willing to step through it yourself or add some logging statements? This is the method that checks if an asset link/name matches the regex:

https://github.com/YahnisElsts/plugin-update-checker/blob/579d537926c41e6d4b82cf2c73f5ba85d96a8e1e/Puc/v5p0/Vcs/ReleaseAssetSupport.php#LL61C28-L61C28

melcarthus commented 1 year ago

Sure no problem. However I failed to mention the repo is a private repo. And maybe it cant find this asset because the link contains no token like the default asset link does have. Or am i overthinking it?

Update

The problem it was not pointing to the correct asset was first of all the delimiters. It would still not point to the right assetslink because of two missing files. Why they where missing when I downloaded the plugin i'm not sure about. But everything is working now as intended!

I was missing ReleaseAssetSupport.php and ReleaseFilteringFeature.php

YahnisElsts commented 1 year ago

Ah, it sounds like there was also a PUC version issue. There have been some changes to how release assets work with the update checker, but I forgot that I haven't published those changes as a new release yet. So you might get different behaviour depending on if you used the 5.0 release or the master branch of this repository.

I'll make a note to release a new PUC version.