Skip to content

Draft: Add support for CI variable to replace support URL

Andrew Conrad requested to merge spt-url-ci-var into master

This partially addresses #50 by adding the ability to add a custom support URL to your status page.

This works through a CI variable (SUPPORT_URL), which means it doesn't require manual replacement or a change in workflow (still works with mirrored repos). If the CI variable is present, it just replaces the couple instances of the previously-hardcoded GitLab support URL.

What still needs to be done

  1. Documentation. I can take care of this after the MR is otherwise in a good state.

  2. Right now, there is a placeholder CI test (test:spt-url) to validate the URL. This could use some regex in the job's shell script to determine if the URL is not obviously invalid, but we have to be careful, because URL validation is tricky. I wondered if this would be better implemented in an additional lint elsewhere in the project.

    Otherwise, we can just not do any validation, and leave this up to the users.

    I am interested in what others have to say about this.

  3. Speaking of lints, right now we have an annoying problem with this MR. If the URL provided by the CI variable is short enough, the linter complains about prettifying this line.

    This, similar to the default URL, is valid (and you can download the artifact it produces):

     <gl-button
       class="gl-mt-5"
       href="https://support.example.com/hc/en-us/requests/new"
       target="_blank"
     >

    This produces an error, failing the pipeline:

     <gl-button
       class="gl-mt-5"
       href="https://spt.example.com"
       target="_blank"
     >

    This is the correction the linter asks for:

     <gl-button class="gl-mt-5" href="https://spt.example.com" target="_blank">

    There isn't a super simple solution to this. After replacing the URL, we could run the lint with --fix to correct it. Otherwise, maybe we can make that lint less strict (warn instead of error, or somehow ignore these lines).

    I'm not sure what the best way to fix this is, but it is essential to accepting this MR.

Edited by Andrew Conrad

Merge request reports