-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
Hi @mcgear! Regarding the differences between the workflows:
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? |
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: Which is already working correctly, and triggering on local push and on plasmic publish. Wondering what concerns you think I should/could have? |
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).
I think this is fine, but two concerns that come to my mind are:
|
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
Is current revision vs latest saved version a plasmic concept/setting? |
In addition, i guess i'm also curious if you would be open to the following addition to both scripts:
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: |
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?
The text was updated successfully, but these errors were encountered: