Github dist (compiled) Release Workflow

I maintain several plugins (both at the .org repo and proprietary ones for clients that I manage in private satis instance to be used by composer on arbitrary projects)ā€¦ the plugins typically uses sass and js - and I use a compilation process (gulp, grunt or webpack depending on the project) to builds the CSS, minifies, concatenates, etc.

every time I make a change, I run my compilation (gulp, grunt or webpack), i commit the compiled files then I manually change the version number in the main file and readme, and then run a commit it usually as ā€œpreparing for 0.3.0ā€ and then tag it and push up which gets consumed by satis running a cron and I can update my arbitrary projectsā€™ composer files to use the newest version.

I know for sure thereā€™s a better way of doing this ā€“ Iā€™d love to keep my repositories clean with just uncompiled files - add a post push hook to run some sort of a build process, set the version numbers, compile and create a dist release on github that would get picked up by my satis and be able to be used my composer for arbitrary projects.

Does anyone have experience doing this? Would I have this build process create a new branch, run the build, create the tag and push up? wouldnā€™t that pollute my repo with commits of compiled files? Thanks for any advice.

Yes, what you are currently using a ā€œdirtyā€ commits where the
built artifacts are also committed together with the source files.

One approach that is also often used in trellis is to build on
workstation + sync the resulting files separately.

That kinda didnā€™t answer my question directly.

I figured a build process would be necessary - Iā€™m asking the how not the what :slight_smile:

You commit your source files, the dist/ files are gitignored (by default, e.g. with sage theme).
On deploy, the trellis deploy task will run the gulp build task in your theme and then rsync the dist/ contents to target server.

heh, thatā€™s not answering my question ā€“ youā€™re answering a question about uncompiled files on a specific theme, Iā€™m asking about (potentially multiple [and many]) individual plugins.

I donā€™t want to add a build process for (potentially multiple [and many]) individual plugins that could get pretty unwieldy quickly.

To summarize this:

  • Plugins in private satis instances
  • These plugins use sass and js and both have to be compiled
  • After each change, manual steps are required for releasing (build + publish) a new version to its satis instance
  • Dist files (build artifacts) are committed together with the source.
  • Youā€™d like to just have the source files in version control without the dist files.

A continuous integration workflow can be helpful here (Jenkins, Travis, CircleCI, ā€¦). Each time the stable branch (often master) is pushed to central repository, a CI server pulls, builds and tests the project and pushes a new release to satis when everything passed, optionally with a manual release trigger step.

Concerning the usage of build artifacts for a release in satis, there is a related mailing list thread:
https://groups.google.com/forum/#!topic/composer-users/KTybYqJosNQ
A ZIP file can be used for satis - which can be also generated by the build task on CI server.

Thanks Starsis.

Just adding a bit more clarity:

The idea is to have 1 git repo for each ā€œpluginā€ ā€“ I could set up two repos in git one called my-plugin-name-src and another called my-plugin-name

I could have a build process that will check out the *-src - build it, commit and tag the non-src repo and have my satis (custom packagist for composer) point to that repo - but that would require two repositories for every plugin - I donā€™t love that solution

What I was hoping for would be some way to build/compile and tag a zip that corresponds to an unbuilt/uncompiled tag in the same github repo - one that allows me to have my composer grab that built one when running composer install/update.

Iā€™ll check out what you linked to. Thanks again.