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

Understanding the difference between plasmic.yml and plasmic-push.yml #1

Open
mcgear opened this issue Nov 29, 2021 · 5 comments
Open
Assignees

Comments

@mcgear
Copy link

mcgear commented Nov 29, 2021

In working with plasmic and our hosting provider LowCodeUnit, I am trying to understand the difference between the plasmic.yml and plasmic-push.yml files. When i make a simple edit to include the artifacts for the -push file it works as expected (as long as I push code):
# publish github artifacts
- name: Archive production artifacts
uses: actions/upload-artifact@v2
with:
name: jeremytomlinson-designsthatadapt
path: ${{ steps.build.outputs.publish_dir }}

If i add the same to the plasmic.yml, it seems to get overwritten every time we publish from the plasmic UI. We need the archive generated, not just eh GitHu pages, what is our best bet?

@tmadeira
Copy link
Contributor

tmadeira commented Dec 1, 2021

Hi @mcgear!

Regarding the differences between the workflows:

  • plasmic.yml is triggered by Plasmic when you hit "Publish" in the top bar of your project. It syncs the project (if it's using codegen, because if it's using loader there's no need to sync), builds and, optionally, deploys it to GitHub pages if you set up a *.plasmic.site domain.
  • plasmic-push.yml is triggered by any push in the "main" branch of your repository, which means it's not triggered when you publish a Plasmic project, but when you make code modifications. It builds and deploys your project, but does not sync it.

The idea of having both is to be able to build your project both when modifications are made in Plasmic (plasmic.yml, syncs project from Plasmic) or in code (plasmic-push.yml, does not sync project from Plasmic).

When you hit "Publish" in Plasmic studio, we overwrite both workflows in your repository. The motivation for that is to allow us to make fixes in the workflows and have control on what they are doing.

The current workaround to run a different workflow controlled by you (i.e., a workflow like plasmic.yml but with your own modifications) is to add a new workflow file (say, plasmic-with-artifacts.yml), configure it to run on a repository_dispatch event (like plasmic.yml) and then set up a webhook on Plasmic to trigger a repository_dispatch event when you hit Publish. Does that work for you?

@mcgear
Copy link
Author

mcgear commented Dec 1, 2021

I think i get what your saying, and that could work for us. When looking at the differences between the builds, if we wanted to support a workflow that supported both plasmic push and code push, which of the two is a better starting point? is it ok to run some of what is in plasmic.yml when also running what is in plasmic-push.yml?

I was looking at using this for our triggers:

on:
repository_dispatch:
types: [plasmic]
push:
branches:
- main

Which is already working correctly, and triggering on local push and on plasmic publish. Wondering what concerns you think I should/could have?

@tmadeira
Copy link
Contributor

tmadeira commented Dec 2, 2021

I think i get what your saying, and that could work for us. When looking at the differences between the builds, if we wanted to support a workflow that supported both plasmic push and code push, which of the two is a better starting point? is it ok to run some of what is in plasmic.yml when also running what is in plasmic-push.yml?

plasmic.yml is probably a better starting point, because it does everything that plasmic-push.yml does and, besides that, it syncs the project (important step if you're using codegen).

Which is already working correctly, and triggering on local push and on plasmic publish. Wondering what concerns you think I should/could have?

I think this is fine, but two concerns that come to my mind are:

  1. The default plasmic.yml (that you don't control) will still be created/triggered when you hit Publish on Plasmic. (As a workaround to avoid that, you could remove the GitHub integration in Plasmic Publish dialog and just set up a webhook that triggers the repository_dispatch event.)
  2. If you sync the project on push, this means every time you push a commit the Plasmic project will be synced and a commit will be made with the new changes. Depending on your setup you may not want that (in particular, if you're using codegen and your project is set to use current revision instead of latest saved version of your Plasmic project).

@mcgear
Copy link
Author

mcgear commented Dec 3, 2021

So with #1, the issue would be a double sync of the project? One by original plasmic.yml, one by my custom script? To avoid this, should/could I rely on plasmic.yml to do the sync on publish, and just worry about the more lightweight -push.yml-esque approach? Is there any reason that file changes made direct to repository would force a need to re-sync plasmic?

with number 2 (i'm still fairly new to plasmic here), when you say

if you're using codegen and your project is set to use current revision instead of latest saved version

Is current revision vs latest saved version a plasmic concept/setting?

@mcgear
Copy link
Author

mcgear commented Dec 3, 2021

In addition, i guess i'm also curious if you would be open to the following addition to both scripts:

  # publish github artifacts
  - name: Archive production artifacts
    uses: actions/upload-artifact@v2
    if: ${{ steps.build.outputs.publish_dir }}
    with:
      name: plasmic-publish-artifact
      path: ${{ steps.build.outputs.publish_dir }}

I could create the PR, and code edits I think. Maybe more of a https://github.com/plasmicapp/tooler question? Can't quite tell where the default .yml files are.

Something like this if I am in the right place for those default files:
https://github.com/plasmicapp/tooler/pull/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants