-
Notifications
You must be signed in to change notification settings - Fork 306
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
v1.3.0 #274
base: main
Are you sure you want to change the base?
v1.3.0 #274
Conversation
|
Still want to test this out more, to make extra sure the list filter expressions and workflow changes are working, but reviewers can start taking a look. |
@@ -21,8 +21,8 @@ jobs: | |||
runs-on: ubuntu-latest | |||
|
|||
steps: | |||
# for debugging | |||
- uses: crazy-max/ghaction-dump-context@v2 | |||
- name: Debug dump |
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.
Gave this a name in several places, just to look a little nicer and more consistent.
@@ -42,14 +42,22 @@ jobs: | |||
id: pages | |||
uses: actions/configure-pages@v4 | |||
|
|||
# for debugging | |||
- if: runner.debug == '1' | |||
- uses: jwalton/gh-find-current-pr@master |
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.
Get PR number in hopefully more robust way (should never be undefined) and use below.
@@ -70,8 +70,8 @@ jobs: | |||
run: | | |||
user="${{ github.repository_owner }}" | |||
description="An engaging 1-3 sentence description of your lab." | |||
printf "USER=${user}" >> $GITHUB_ENV | |||
printf "DESCRIPTION=${description}" >> $GITHUB_ENV | |||
printf "\nUSER=${user}" >> $GITHUB_ENV |
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.
$GITHUB_ENV
seems to act like a regular .env
file. Forgot to add new lines here, so these vars were getting messed up like:
OTHER_VAR=other value
USER=some-usernameDESCRIPTION=description of lab
steps.changed.outputs.files_changed == 'true' && | ||
inputs.open-pr == true | ||
uses: peter-evans/create-pull-request@v6 | ||
with: | ||
branch: citation-update | ||
title: Periodic citation update | ||
body: | | ||
To see a live preview of this PR, close (not merge) and reopen it. |
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.
When opening a PR from on-schedule
citation update, this gives some instructions for how to trigger the PR workflow.
@@ -7,13 +7,13 @@ | |||
class="button" | |||
href="{{ button.link | replace: "$LINK", button.link | relative_url }}" | |||
{% if button.tooltip %} | |||
data-tooltip="{{ button.tooltip }}" | |||
data-tooltip="{{ button.tooltip | xml_escape }}" |
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.
Add this in a bunch of places to prevent HTML parsing errors, e.g. button.tooltip
having a value of "Effective" methods of communication
(where the quotes screw up data-tooltip=""
).
# filter a list of hashes by comma-sep'd field:value pairs | ||
def data_filter(data, filters) | ||
if not data.is_a?(Array) or not filters.is_a?(String) | ||
|
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.
Here's the tricky and weird part.
Takes a list/array of some data and a simple filter string. For each item... define "item" as a local Ruby variable with the value of the item itself. Then also, for each key/property on the item, define that as a local variable. Then evaluate the filter string as Ruby code with all those local variables available to use. If the filter string has something that's not in the item, catch that error, define that variable as null, then try again. When the filter string is able to be executed without errors, keep/discard the item based on whether it returns truthy/falsey.
@cgreene I think this review is going to fall on you, as it's more of a philosophical design change than a technical change, aside from the one section of code that supports the Ruby expression filtering which is a little weird. I've also "annotated" the diff with comments that hopefully will make it easier to read. |
Closes #272
Closes #269
Closes #191 (hopefully)
New template version checklist:
name
field for all debug/logging steps in workflowsjwalton/gh-find-current-pr
to get PR number to be more reliable (in rare cases,github.event.number
can be empty)description
gets appended touser
due to missing\n
in printf.yml
to.yaml
for consistencyif
skipping instead of job-level or workflow-level because of this issue.xml_escape
liquid filter wherever a user/third-party provided field is used in an HTML attribute to prevent special characters breaking HTML rendering. example:aria-label="{{ citation.title }}"
andcitation.title
is"Lorem Ipsum" dataset
, causing attribute to prematurely close.data_filter
to accept Ruby expressions instead of custom syntax. use Rubyeval
and define each field in the item as a local variable, e.g.{"animal": "cat"}
lets you usefilter="animal == 'cat'"
.<details>
element† due to a github limitation, it wouldn't not run anyway on the auto-created PR. the user must close/reopen the PR, then the regular "on pr" workflow (which includes running "build preview") will run. i've already updated the docs to talk about this. from now on, let's treat auto-opening PR as the only supported way. previously i considered that the user could change
open-pr
tofalse
to have "on schedule" commit updated citations directly tomain
, but let's nix that to maintain simplicity. it's probably better that we force the user to review the changes before pushing them to their live site anyway. if we did want to support that in the future, the "build preview" run i removed would have to be changed to a "build site", since we'd want to be re-building themain
branch version of the site, not a preview for a PR.