Where are /public/assets generated in the go buffalo workflow?

user_350542 0
Viewed 411

In go buffalo, there is a generated .gitignore file which ignores public/assets. However, at the same time, the generated css and js are critical for getting a 'real' buffalo app. So, there's a disconnect which I don't fully understand, which is that something seemingly critical for deploying an app is bound to be missing, by default, from any version control system which builds the app itself.

What I've noticed

  • buffalo build does not generate content in public/assets.

  • buffalo dev also does not generate this content.

  • running buffalo dev after deleting public/assets/* results in a site that doesn't have any CSS, implying that it breaks functionality.

So, thus. from what I can tell /public/assets are both essential, and non-dynamically created.

So, my question is thus, how can i regenerate public/assets in my buffalo workflow at build time (i.e. how can i retain the .gitignore defaults) or where do people generally package their assets if not in version control?

buffalo assets go css
2 Answers

So to answer the original question of where public/assets are generated - the answer is "at creation time" or "at build time, if you dont have them, and if you bootstrap the empty directory". Hopefully after the PR mentioned below is merged, the answer to this question will be "at creation time, or at build time if they don't already exist in your repo (i.e. because they are gitignored)".

The two points (why local build doesnt generate them + why docker build doesnt generate them) have completely unrelated and different answers, so I'll treat them each in separate bullets.

  • We've found that actually, depending on the state of your repository, if you lose/delete the webpack files, the buffalo environment doesn't regenerate them for you, and thats not a bug in anyway, because its a valid use case to run buffalo without generating any assets (although this is not a use case which seems very useful to me, it might be worth proposing a change to make buffalo more opinionated in this regard).

  • Regarding the docker build itself, it seems that if you add a mkdir statement to ensure that public/assets exists before running buffalo build (i.e. in your Dockerfile), then you can compensate for the fact that you are git-ignoring that directory, and it will correctly be populated in the static build.

Since the latter use case is the more important one, I've created a pull request to address this issue (i.e. to make it so that you don't need to manually add a mkdir public/assets step) under the guidance of the buffalo community, which can be found here: https://github.com/gobuffalo/buffalo/pull/1447.

In short : Until this PR merges, if you need your assets to build your deployables (which you probably do), either remove the public/assets line from gitignore and commit them to version control so that your code can directly be built with no external dependencies, OR just make sure you build your code in the same place that you run buffalo dev. If there is a third answer. The former is the more cloud friendly solution from my perspective, but I'm new to buffalo so I may be misunderstanding the idioms in some ways.

Disclaimer: I'm answering this question because I think it might be useful to folks, but I'm not a buffalo expert. There are much deeper technical perspectives on how assets work on the buffalo docs/website (https://gobuffalo.io/en/docs/assets)

user_3505420

There's source control, which contains the source you've created for your application, there's the build server, which turns the source into deployable artifact(s), and there's artifacts, which contain everything necessary to run the app (i.e. resources, compiled binary, no source code).

Source control is generally a poor solution for storing artifacts; this is why e.g. GitHub has the Releases feature. Find a proper solution for your artifacts, outside of source control - what you choose will depend on your build and operating environments and your deployment system. For example, S3 is a popular choice for storing internal build artifacts because it's very easy to use and reasonably cheap.

user_74260
Related