I’ll fix it up tonight. I’ve just started a new job (which requires me to fly to Sydney in a couple hours), so I don’t have time until then. Because of that I also missed the release of 0.16 or I would’ve tested it already. So in about 14 hours there should be a fix. Or if anyone else provides it before then I’ll merge and release.
I think I already fixed it. I remembered I made some changes that should ease this so I did it on my iPad while waiting for my flight. That does mean there was minimal testing, but previous versions aren’t impacted at all so in the worst case that means it still doesn’t work. I’m pretty confident 0.16 will work now though.
Hmm. It seems that even though I have version: 0.15 set in my wercker.yml, it’s trying to build with 0.16, which is breaking some stuff for us (that is, I see issues with the built site but I don’t see them locally where I haven’t updated hugo yet).
I looked at the logs, and it doesn’t seem like wercker is even looking at the version:
OK, I am setting up a new site/build with Wercker (which now forces you into this “workflow” thingy.
Anyway, so here’s what I get with the build as output now:
Started building site
=============================================================
Your rendered home page is blank: /index.html is zero-length
* Did you specify a theme on the command-line or in your
"config.toml" file? (Current theme: "grid-side")
* For more debugging information, run "hugo -v"
=============================================================
0 draft content
0 future content
2641 pages created
1417 non-page files copied
0 paginator pages created
29 categories created
222 tags created
in 1420 ms
Its my first post so i hope i dont ask it the wrong way ;=)
My Wercker is somehow working… but also not working. And i have no clue now why this is happening.
is my wercker file… everything goes well and it deploy’s what i want to my gh-pages… The problem i have is if i add a new site it does not create the static pages in the public folder.
Do i have to execute (after the hugo build) a shell command in wercker or should this automatically be done in the hugo build?
I mean on wercker i dont wanna start a server (dont even know if thats allowed) so im asking the pro’s here how i tell hugo with wercker to generate all sites.
Thanks for a answer
*** EDIT ***
Did found the error… everything was correct, problem was that if a *.md article has twice the same content it does not get rendered by hugo. Was everything correct no error.
@ArjenSchwarz (or anyone else). For whatever reason, using the same Wercker file I always used before, I’m getting the following error in my S3 sync step:
ERROR: S3 error: 403 (InvalidAccessKeyId): The AWS Access Key Id you provided does not exist in our records.
Odd, since I have no issue updating directly from the command line…thoughts?
@rdwatters it sounds a lot like its an issue with the S3 credentials. Are you using the same access key from your local machine as you are from Wercker?
That was my first though, but I pulled the key and secret key directly from ~/.aws/credentials, deleted the old $AWS_KEY and $AWS_SECRET_KEY and recreated those variables under the environment tab in Wercker, and still no lucky, oddly.
The odd thing is that in my pipeline I have a build and deploy and even an after-steps for Slack. They all say the build is passing, and I get zero notifications for this error. However, under the deploy step for S3 Sync, I still get the following error starting at around line 40ish:
/pipeline/s3sync-88ff0694-9724-46a2-98fe-5e1b3f1adccb/s3cmd sync --add-header=Cache-Control:max-age=100 --delete-removed --verbose ./ s3://digital.cap.org
INFO: Compiling list of local files...
INFO: Running stat() and reading/calculating MD5 values on 242 files, this may take some time...
INFO: Retrieving list of remote files for s3://digital.cap.org/ ...
INFO: Forwarding request to us-east-1
ERROR: S3 error: 403 (InvalidAccessKeyId): The AWS Access Key Id you provided does not exist in our records.
finished s3 synchronisation
The public key that writes to the console in Wercker, btw, is accurate. Hmmmm…
@rdwatters that’s strange. Both that it still marks it as successful and that it fails on this in the first place.
Maybe it’s something in your wercker.yml file? I assume you haven’t made any changes to it, but we have to start somewhere. One of my sites where I use s3sync has the following configuration for it.
You’re obviously using different values with $AWS_KEY and $AWS_SECRET_KEY, but they are still assigned correctly to key_id and key_secret?
The other difference here might be that I use my own version of s3sync, instead of the Wercker default one. This is because the Wercker one didn’t fail on errors, and my fork fixed that by using a newer version of the underlying command. I believe Wercker have since updated their version, so that shouldn’t be an issue anymore, but I kept using my fork because it worked so there was no point in changing it. You could try using my version, just in case that solves the not failing part.
Yes, it’s really odd that this error is only being thrown in the S3 Sync and that I don’t have any issues pushing the site to the bucket from the command line. Here is my wercker.yml:
I have $AWS_KEY assigned to aws_access_key_id in my /.aws/credentials and $AWS_SECRET_KEY assigned to aws_secret_access_key. Although slightly different than your config, $AWS_BUCKET is correctly assigned to AWS_BUCKET in my Wercker environment. Thanks for the feedback, @ArjenSchwarz!
##AS AN ASIDE…
I’m wondering if anyone has experience leveraging Wercker for image resizing using Gulp. I have this as part of my local build, but I’m not sure if I can add node and golang in a pipeline…
Ok, I have to think about what could be the problem here @rdwatters as nothing comes to mind right now. Although, I remember in the past that you had some issues with IP-based credentials. Is it possible that it’s related to that? It doesn’t match the error message, but that could be a bug in the error.
As for your aside, while I haven’t done it myself I can tell you that it’s possible. There are a couple of things that make this easier, both changes in Wercker and changes in the hugo-build step.
First, the hugo-build step now already includes the binaries for the latest 3 releases of Hugo, meaning that it can run from any container so you’re not limited to for example the golang one. It will always be only the latest 3, due to size limitations in the step, but that shouldn’t be a major issue.
Secondly, Wercker has made their environment more fluid. Meaning you can for example have multiple build pipelines that each use a different container and the contents (or rather, the contents of the $WERCKER_OUTPUT_DIR/$WERCKER_SOURCE_DIR) get passed along to the next pipeline just like it is between your build and deploy steps. So, in theory you can have a prepare-images pipeline using a node container, and then a build-hugo pipeline using a golang container. Their documentation about this can be found here.
Hi, I have problem with wercker that i cant seem to solve, I have build that utilizes gulp and I want to build my assets than use hugo to build the site which works fine but i cant seem to get my head around why does build task starts when deploy gets finished.
It does finish note that i don’t want build files in my gh-pages branch so i made inline script that changes .gitignore to the new one, and build does pass but when it finishes it automatically calls build on new branch how do i stop that ?
A quick look seems to indicate the problem is with the code in the Wercker step. It’s probably trying to download a wrong URL (the naming scheme for the files has changed a number of times over the years so it might be using an old one). Thanks for letting me know, and I’ll have a look soon (today/tomorrow) to get it fixed. I’ve created an issue in the GitHub repo about it at https://github.com/ArjenSchwarz/wercker-step-hugo-build/issues/49