Skip to content
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

Journal: Author provides Entry#summary #2161

Merged

Conversation

zspencer
Copy link
Member

@zspencer zspencer commented Jan 29, 2024

@zspencer zspencer added the ✨ feature Reduces Client's Burden or Grants them Benefits label Jan 29, 2024
@zspencer zspencer closed this Jan 30, 2024
@zspencer zspencer reopened this Jan 30, 2024
@zspencer zspencer marked this pull request as ready for review January 31, 2024 02:25
@zspencer zspencer requested review from a team January 31, 2024 02:25
@zspencer zspencer changed the title Journal: Add an Entry#summary Journal: Author provides Entry#summary Jan 31, 2024
@zspencer zspencer changed the title Journal: Author provides Entry#summary Journal: Author provides Entry#summary Jan 31, 2024
- name: Run Tests
env:
HEADLESS: true
run: bundle exec rspec spec/furniture/journal
Copy link
Contributor

Choose a reason for hiding this comment

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

What about excluding these tests from .github/workflows/test-convene-web.yml?

Copy link
Member Author

Choose a reason for hiding this comment

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

I have some Ideas re: how to refactor our CI to split things out; but I don't know enough about the Github Actions syntax to do it.

Ideally we would have:

  • An Action that creates a Slug w/all the Dev + Test dependencies
  • A set of Actions that execute the tests for each Gizmo
  • An Action that executes the tests for the OS itself

That way as we add gizmos the total test suite time doesn't go up.

But I also think that's a thing to deal with on a different day; once we decide it's worth it.

- #10

What I'm driving towards here is similar to
zinc-collective#2055, where a
`Journal::Entry` has an affordance for being opinionated about how it's
represented when linked to in search engines or peer-to-peer sharing; as
well as short text for when there are a several on `Journal#show`.
While working on
#11, I realized I
missed a piece of the refactor because I was leaning-on-ci as a way to
confirm that everything was working as expected.

Little did I know, CI was not working in this fork. Which makes sense,
because you don't want to automatically turn on all the Workflows when
you fork a project.

This adds a Github Workflow for testing *just* the `Journal`, which
should make detecting oopsie-daisys a bit easier for folks who are only
interested in working on the Journal.
- #10
- #2

This is a quick line-of-action end-to-end test for setting an `Entry#summary`.
- #2
- #10

And just like that, there's a `Summary` field on the
`Journal::Entry#new` page!
@zspencer zspencer enabled auto-merge (squash) February 3, 2024 20:21
@zspencer zspencer merged commit 64cc4aa into zinc-collective:main Feb 3, 2024
3 checks passed
@zspencer zspencer deleted the journal/entry-summaries branch February 3, 2024 20:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ feature Reduces Client's Burden or Grants them Benefits
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants