The docs state that the initial_version parameter is optional. However if you are using the Swift driver and do not specify it explicitly you will get the following error:

Initial version was not a valid sem ver

Concourse 4.0.0

I marked a version as 'invalid', then proceeded to bump it.

The version it 'gets' is 0.0.0, yet it bumps it to 0.1.1 meaning it started from the 'bad' version. Seems like it's improperly using the cache or something.

- name: bump-patch
  serial_groups:
  - version
  plan:
  - get: version
  - put: version
    params:
      bump: patch

I thought maybe it was an 'atomic put' issue cause I was doing an unnecessary get, I think?

So I removed the - get: version line from bump-patch and tried marking the latest version as invalid again, and then 'bumping' it, and it still just immediately bumped to 0.1.2, again ignoring the fact that 0.1.1 was marked as 'bad' and the only remaining good version is 0.0.0

(I didn't grab a screenshot before it made 0.1.2, but you can see that 0.0.0 should have been the only valid version)

The README indicates that if there are no build args, all tests but the integration tests will run. However, running docker build -t semver-resource . gives the following error:

Failure [0.000 seconds]
[BeforeSuite] BeforeSuite
/go/src/github.com/concourse/semver-resource/check/check_suite_test.go:20

  must specify $SEMVER_TESTING_ACCESS_KEY_ID
  Expected
      <string>:
  not to be empty

  /go/src/github.com/concourse/semver-resource/check/check_suite_test.go:23

It seems like this shouldn't happen, or at least the README should be updated to remove the command without build args.

I have some tasks that span jobs in a pipeline that do exactly the same thing except for version number resources. What I'd really like to do is use the semver resource to output to a different directory so that I only need the one task file, and can have version/version as one input to it.

my setup is something like this:

task-requiring-version.yml

---
platform: linux

image_resource:
  type: docker-image
  source:
    repository: custom-docker-image

inputs:
  - name: pipelines
  - name: version
  
run:
  path: /bin/bash
  args: 
  - -cel
  - |
    # Do stuff requiring the version
    export version=$(cat ${version/version})
    # and so on

another-task-requiring-different-version.yml

---
platform: linux

image_resource:
  type: docker-image
  source:
    repository: custom-docker-image

inputs:
  - name: pipelines
  - name: different-version
  
run:
  path: /bin/bash
  args: 
  - -cel
  - |
    # Do stuff requiring the version
    export version=$(cat ${different-version/version})
    # and so on

pipeline.yml

- name: deploy app 1
  plan:
  - aggregate:
    - get: pipelines
    - get: version
      passed: ["previous step"] # where the version got bumped

  - task: Deploy
    file: pipelines/tasks/deploy-app-1.yml
  
  - task: Check application health
    file: pipelines/tasks/task-requiring-version.yml

- name: deploy app 2
  plan:
  - aggregate:
    - get: pipelines
    - get: different-version
      passed: ["previous other step"] # where the different-version got bumped

  - task: Deploy
    file: pipelines/tasks/deploy-app-2.yml
  
  - task: Check application health
    file: pipelines/tasks/another-task-requiring-different-version.yml.yml

# and so on

where as what I think I'd like is:

pipeline.yml

- name: deploy app 1
  plan:
  - aggregate:
    - get: pipelines
    - get: version
      passed: ["previous step"] # where the version got bumped

  - task: Deploy
    file: pipelines/tasks/deploy-app-1.yml
  
  - task: Check application health
    file: pipelines/tasks/task-requiring-version.yml

- name: deploy app 2
  plan:
  - aggregate:
    - get: pipelines
    - get: different-version
      params: {out-dir: version}
      passed: ["previous other step"] # where the different-version got bumped

  - task: Deploy
    file: pipelines/tasks/deploy-app-1.yml
  
  - task: Check application health
    file: pipelines/tasks/task-requiring-version.yml

# and so on

If there's already a known way of doing this that doesn't require another task to copy the versions to task outputs (which would require the same custom tasks, just doing something different), I'd appreciate being told how. Otherwise, does this sound like a feasible enhancement?

Hi,

I'd like to store version in Git repository. However, I'm falling into build loop if I'm not ignoring "version" file. If I do ignore "version" file, this leads to lost commits in future jobs (as they are ignored) and I'm unable to push back to repository. Perhaps someone has an idea how to solve this?

We are evaluating moving our builds from 1.0.0.beta-1 to 1.0.0.build-1 similar to how Pivotal is versioning the tiles that they release on pivnet. We see a lot of benefits in this versioning scheme in that we would be able to build the artifact once (in this case a spring boot application) and promote it through the pipeline and not have to rebuild it when shiping it as a release. Instead we would move the preelease from the pre-release repository to the release repository and the binary will not change or the version. Is this feasible with the semver-resource in concourse? Is there a different resource that we might look at? Is this the same resource that Pivotal release engineering uses for versioning their tiles?

When you bump final a semver that's already final, I want the patch to be bumped. Currently, a new version is not produced.

Current:
1.0.0 --> bump final --> 1.0.0

Proposed:
1.0.0 --> bump final --> 1.0.1

When you bump pre a semver that's already final, I want the patch to be bumped, with the pre applied after. Currently, the pre is applied to the final semver, going backwards.

Current:
1.0.0 --> bump pre build --> 1.0.0-build.1

Proposed:
1.0.0 --> bump pre build --> 1.0.1-build.1

I'm using a script to to work around this currently, it would be nice to get away from that so I can have the above behaviour applied atomically.

UAA team has forked from this repo and realized we recently started having some failures when running the test/check.sh tests during build of the Docker image. We have found that the same failure is exhibited in this repo as well.

Specifically, there is a test in test/check.sh called it_fails_if_key_has_password which attempts to run check given a private key encrypted with a passphrase. It appears the GitDriver attempts to inspect the contents of the private key to verify whether or not it is encrypted. Also, kind of related to this: there don't appear to be any unit tests for the GitDriver, don't know if we missed them or this was intentional?

Problem is that the newer generation of keys through ssh-keygen no longer contain headers indicating whether or not the key is encrypted. This invalidates the logic linked above by considering the key to be valid and being able to successfully fetch the version from the bucket when it shouldn't. (At least in that it_fails_if_key_has_password test)

We are looking into a fix for ourselves and can send one your way or hold off, up to y'all.

Thanks!

~ Jwal & @bruce-ricard

If you have a long pipeline with a bunch of checks until you get to the point you would like to version it there might be new changes added to the git repo. When a git driver is used it is very misleading to assume that the commit that changes the file from one version to another (which is out of the concourse control) is a delimiter between versions - if you do it in the same repo - because the actual version change potentially happened several commits earlier.

With git-tag used as versioning - this issue seems even more severe because intuitively the tag is put on the exact commit.

This is a sample implementation that overcomes this issue with getting as argument the git_resource and taking the sha from it: https://github.com/ggeorgiev/semver-resource/tree/my_ci

The tests on ci.concourse.ci for the resource do not currently run the tests for the swift driver, but do for the git and s3 driver. To be better citizens, we should run all the things!

It would be worth an investigation to have the tests run against a mock swift server.

When I use the git driver and store the version(s) at the root of the repo, the version file is created if it doesn't exist. However, when the "file" property is a path, semver-resource will throw an error:

error setting version: open /tmp/semver-git-repo/environment-a/team-2/application-x: no such file or directory

This means that I need to create the appropriate directory set up manually before using this on a new application. I suppose that s3 driver behavior is different as S3 doesnt care about directories.

Would it be possible to introduce a small "mkdir -p" kind of step before attempting to store the file?

Currently, parsing the content of a semver file fails is there is trailing whitespace (\r, \n, \t, etc.) after the semantic version string. I don't see any specifics about trailing whitespace in the current semver spec, so additional whitespace could be considered "invalid".

It would be much more "user-friendly", however, for the Concourse resource to trim extraneous whitespace from the contents of the semver file. I say this because the most obvious end-user workflow (at least to me) creates an invalid resource.

echo 0.1.0 > myversion`
aws s3 cp myversion s3://mybucket/myversion

... create pipeline referencing the S3 bucket above as a "semver" resource

fly -t my-ci-server set-pipeline -p my-pipeline -c my-pipeline.yml
fly -t my-ci-server check-resource -r my-pipeline/my-semver-resource

The last command will return an error message like:
error checking for new versions: parsing number in bucket: Invalid character(s) found in patch number "0\n"

I was able to work around the error by using echo -n to generate the initial semver file, but that was definitely non-obvious. I also tried creating the file using vi, vim, emacs, nano, and GEdit on my Ubuntu 16.04 system. From what I saw, the default behavior of all of them was to include a trailing newline character in the file.

Currently you can only set the commit message in the sourceblock. We ran in to a case where following what is going on in the pipeline would be simplified by being able to set the commit message in params on the put step.

Is there a way to determine the bump type based on outside factors within a single job?

For example: I want to bump the minor version when, based on our ticketing system, a new feature is what sparked the pipeline, but bump only the patch version when a bug fix is what triggered things.
I came up with a theoretical solution but it requires multiple jobs and I wanted to make sure I wasn't hacking something that someone already elegantly solved.

what would people view be on adding support for tagging the bumping commits by the git driver?

I'm thinking something like an also_tag flag in the resource setup.

We'd really like to use git tags as the backend for semver so that we can automatically version our code repositories. It's possible to implement this now using a separate semver storage repo and the git resource, however it's possible for the two repositories to fall out of sync.

Opening this here as we've expressed interest in working on it in Slack and were told it would be accepted upstream.

GCS sets a 3600 second max-age for objects uploaded to GCS buckets:

Unless otherwise specified, the Cache-Control setting for publicly accessible objects is 3600 seconds ... If you allow caching, at download time you might see older versions of objects, even after uploading a newer replacement object, because the older objects remain in the cache for a period of time.

This means that when I put to a semver-resource, I might not be able to successfully get that version back for up to an hour.

This causes some fascinating misbehaviour. The only current workaround is to manually set Cache-Control headers in the bucket. But this means that I have a task following around after every put, which isn't very convenient.

Google suggest setting Cache-Control: private to prevent caching. Can we please see if this improves behaviour?

We have a bump major version job like this:

  - name: garden-runc-bump-major-version
    serial: true
    plan:
    - get: gr-version
      params: {bump: major, pre: rc}
    - put: gr-version
      params: {file: gr-version/number}

It looks like when it was last ran the version 1.2.1-rc.42 was fetched and locally bumped to 1.3.0-rc.1 but we checked the backing s3 file and it was containing 1.2.2-rc.3 which means that most probably the 1.3.0-rc.1 version failed to be pushed back to s3 and the error was silently ignored by semver resource.

Here is a screenshot:

We are using the semver resource with a GCS bucket. We are seeing intermittent, frequent failures to PUT the semver resource. However, it succeeds sometimes.
We started seeing this two days ago, and 10 out of the last 18 builds have failed for this reason. (and out of the last 11 builds, 8 failed) This is adding significant flakiness to our pipeline.

We get the following error during the put (not during the subsequent get):

error bumping version: InvalidAuthentication: The provided authentication header is invalid.
	status code: 400, request id: , host id: 

Our resource is configured as follows:

- name: release-version
  type: semver
  source:
    key: release-version
    access_key_id: ((gcs-access-key-id))
    secret_access_key: ((gcs-secret-access-key))
    bucket: our-pipeline-store
    region_name: us-east1
    endpoint: storage.googleapis.com

We're doing a put with build params:

- put: release-version
      params: {pre: build}

We are using concourse version 3.8.0.

While git-resource supports ed25519 keys, semver-resource does not. This was fairly confusing as I was using the same credentials for both resources, but the semver resource was failing as if I had not supplied any key at all:

resource script '/opt/resource/check []' failed: exit status 1

stderr:
Cloning into '/tmp/semver-git-repo'...
Warning: Permanently added 'gist.github.com,192.30.253.119' (RSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error checking for new versions: exit status 128

Switching to an RSA key fixes the error.

Please add ed25519 support to this resource so it behaves like git-resource. Thank you!

It is not documented that using semver with the swift driver requires the use of the openstack key.

This does not work.

- name: version
  type: semver
  source:
    driver: swift
    container: bgd-version
    item_name: version
    region: dallas
    ...

Whereas this does:

- name: version
  type: semver
  source:
    driver: swift
    openstack:
      container: bgd-version
      item_name: version
      region: dallas
      ...

Hi,

I created a PR to add the possibility to give the user information when pushing to the repository.

#10

Config:

resources:
[...]
  - name: version
    type: semver
    source:
      initial_version: 0.0.0-pr.((pr-name)).0
      driver: git
      branch: pipeline-state
      file: ((pr-name)).version
      uri: https://bitbucket/scm/prj/repo.git
[...]
  - name: increment-pr
    serial_groups: [version]
    plan:
    - aggregate:
      - get: source
        trigger: true
      - get: version
        params: {pre: pr.((pr-name))}
    - put: source
      params:
        repository: source
    - put: version
      params: {file: version/number}

When the increment-pr task runs, I get the same output as the input:
bumped locally from 1.1.2-pr.project-pr-chad-pipeline-test.1 to 1.1.2-pr.project-pr-chad-pipeline-test.1

Any idea why the patch isn't bumping? Does it not like/allow a period?
The value of pre can be anything you like; the value will be pre-pended (hah) to a numeric value.

Hello,

Our team stores more than one version in a single repository, where each version is on the same patch version but the build numbers are being bumped frequently. We sometimes see output like this in our git log:

* 593fa78f - bump to 1.12.0-build.124 (10 hours ago) <git>
* 9a3cb01e - bump to 1.12.0-build.12 (11 hours ago) <git>
* 894166d4 - bump to 1.12.0-build.123 (12 hours ago) <git>
* 224c253b - bump to 1.12.0-build.11 (17 hours ago) <git>
* 4d4c4aa2 - bump to 1.12.0-build.122 (17 hours ago) <git>

It would be helpful if these messages were more unique, perhaps by including the path to the version file, to reduce confusion when working in the same repository.

Thanks!
Dave

When tagging, it always tags HEAD, instead of the revision pulled with get. This makes it impossible to do something like:

jobs:
- name: first
  steps:
  - get: source
  - task: <build>
- name: second
  steps:
  - get: source
    passed: [first]
  - put: source
    params:
      tag: foo
      only_tag: true

Hello.

We use Concourse with semver-resource to build the project.

This is how it is set up:

• get: git
• put: version
  params: {bump: patch}
• put: docker-image

The next question came up.

If a particular build failed, how do we rebuild a project with the same version?

Now I only thought of increasing the version in advance at the end of the build, but it looks clumsy.

Of course, we can remove put steps in the build manifest, but I think there should be a better solution.

Thank you in advance.

In the original code, isPrivateKeyEncrypted is called before Concourse writes the key if it does not yet exist. As a result, isPrivateKeyEncryptedalways returns an err because it is invoking ssh-keygen on a non-existent file, and Concourse bails out. Changing the sequencing restores order to the Force.

https://github.com/VulcanTechnologies/semver-resource/blob/fix-ssh-check/driver/git.go#L203-L221
edited 2020/07/16 to add the patched snippet here which was linked above

func (driver *GitDriver) setUpKey() error {
	_, err := os.Stat(privateKeyPath)
	if err != nil {
		if os.IsNotExist(err) {
			err := ioutil.WriteFile(privateKeyPath, []byte(driver.PrivateKey), 0600)
			if err != nil {
				return err
			}
		} else {
			return err
		}
	}

	if isPrivateKeyEncrypted() {
		return ErrEncryptedKey
	}

	return os.Setenv("GIT_SSH_COMMAND", "ssh -o StrictHostKeyChecking=no -i "+privateKeyPath)
}

This bug was introduced in #77. Like @wjjackson7, I find the lack of unit tests disturbing.

Without those, I'm not going to turn this into a PR, but the workaround is documented for them that stumble here.

If using a s3 instance that uses an internal CA cert need ability to ignore ssl verification

It would be neat if there were an optional flag to create the specified semver branch if it doesn't exist on remote. I'm imaging something similar to how initial_version: will create & initialize the semver file for you if it doesn't exist.

Has anyone tried something like this / any potential problems with this I might not be seeing?

Thanks!

An optional prefix argument that allows for multiple version tracking in the same git repo.

If you have release branches, or if you track more than one project (or component) you might need to isolate one version tracker from another. This could be easily done with a tag prefix.

I’m using a semver resource where the version number is stored in git. Now I want to use the version number in the filename of the build file that is stored in a S3 bucket. We have the pipeline pointing to a separate task-file which points to a shell script. It is in that shell script that I want to use the version as a variable. Now in the shell file the version variable is replaced by the literal argument text [version/number] instead of with the actual version number.

How would I use the version number from the resource in this case?

The git driver does not support skipping the ssl verification step, while the s3 driver already can (see #50).

Something similar as in #50 could be done here.

Hi,

I made the embarassing mistake of missing off the bucket value in the params for the S3 driver. This caused the following error message on out (but not in):

error bumping version: MalformedXML: This happens when the user sends a malformed xml (xml that doesn't conform to the published xsd) for the configuration. The error message, "The XML you provided was not well-formed or did not validate against our published schema."
status code: 400, request_id: 80a9032b:14b587dc17b:b083f:45, host id:

This was against an EMC ECS Appliance - potentially the error message would be different against another S3 compatible blobstore.

If a fundamental setting is omitted for a particular driver it would be great to have a more obvious error message.

Thanks,

Theo

I think it's good to decide to what version to go in a plan.
Than I want to add two new params: bump_file and pre_file
With this I can set this params in another task to pass
And only one of this is need to pass: bump or bump_file and pre or pre_file

Thanks

I have configured our build like this:

- get: version
    params: {bump: patch}
  - task: "our_build_task"
       <redacted>
  - put: version

- name: version
  type: semver
  source:
    initial_version: 0.0.0
    driver: git
    uri: [email protected]:<redacted>.git
    branch: master
    private_key: ((github_private_key))
    file: version

Which results in no version bump specified when the put executes. My expectation is that it would bump the version file locally before running the build then put that version. We are running concourse 3.9.2...I just noticed 3.10.0 is available, would an upgrade fix this? and/or should we pull in the semver recourse type rather than use the integrated version?

We wrote tasks that allow us to quickly roll back a deployment based on a previous version. We also track the currently deployed version so that we can restart / redeploy.

When we 'roll back' a version and push that version to a file using the git driver - the resource will not 'discover' it as new since the version has shown in the past.

version=1.0.0 
// Deploy New
version=2.0.0
// Roll Back
version=1.0.0 

After the last step - version correctly stores 1.0.0 but still reports 2.0.0 in concourse due to this behavior.

it returns the version specified in the file if it is equal to or greater than current version, otherwise it returns no versions.

I would like to propose an option like below

- name: version
  type: semver
  source:
    driver: git
    allow_duplicate_versions: true

If this is a feature that could be included - I can work on a PR

We had a build CI in fail to push the bump commit using the git driver even though the put step went green. We think this is due to the retry logic here. In that event that the git commit succeeds but the git push fails, the method is retried but will exit without pushing as it thinks there is nothing to commit.

We also noticed in this that the get step does not do any sanity checking to make sure that the version passed to it via the request matches the version that's located on disk. If this mismatch were caught, we would have seen it fail in the implicit get afterwards. We think the fact that it stopped looking at disk happened in this commit. Adding this behavior might be tricky if you are dealing with storage that's eventually consistent (like S3).

I'm using IAM Roles for EC2 security credentials. In trying to use the S3 driver, it looks as though the SessionToken must also be set. Just using the AccessKeyID and SecretAccessKey values results in an error:

resource script '/opt/resource/check []' failed: exit status 1

stderr:
error checking for new versions: InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records.
    status code: 403, request id: XXXXXXXXXXXXXXXX

I didn't see a way to provide the SessionToken to NewStaticCredentials.

I get this error:

resource script '/opt/resource/check []' failed: exit status 1

stderr:
Cloning into '/tmp/semver-git-repo'...
fatal: could not read Username for 'https://bengtssondd.it': No such device or address
error checking for new versions: exit status 128`

On my:

• MacOS v10.13.6
• Docker v18.06.1-ce-mac73
• Docker compose v1.22
• Concourse CI v4.2.1

The config for semver in my pipeline YAML is:

- name: version
  type: semver
  source:
    branch: version
    driver: git
    file: version
    initial_version: 1.2.1
    password: ((myuser_pass))
    uri: https://bengtssondd.it/git/healops.git
    username: myuser

I have tried:

• Downgradring to v3.10 of ConourseCI where it used to work. Now it doesn't
• Thinking about what I've changed:
  -- Using a docker-compose v3.2 file
  -- Postgres v10.5
• I tried again on another Macbook I have. And no error. It works. But why in the world. It do have a newer version of Git installed. But is that really it? Does the semver and git resources really use the local version of Git? What is going on here? Would be great to get a clearer view on this issue. Thank you.
• Tried updating Git on the non-working Mac. Even did a full Docker restart on MacOS. And a full re-install of ConcourseCI, removed the Postgres volume.

N.B. 2FA is not enabled on the Git setup I'm using.

What in the world could be wrong?

https://media.giphy.com/media/fExunDejohBMQ/giphy.gif

When is the next release planned? I would like to use the "pre without version" feature, but I would have to use the "dev" tag of the semver resource docker in order to use it, since the current latest version is 5 months old and predates that feature.

It takes up to 5 minutes or even more when using semver-resource's git driver to clone a repository with a very very long history. Git driver can be improved with following options:

1. Using git --single-branch option to clone only version's branch history
2. Enable using of git --depth option to make a shallow clone of repository

I'm going to propose a PR with those changes

While we configuring pipeline with semver-resource, we noticed this resource doesn't support https_tunnel. As per our security requirement SSH over proxy is disabled so we need this https_tunnel to make it work.
Any work around we can do?

stderr:
Cloning into '/tmp/semver-git-repo'...
ssh: connect to host github.com port 22: Operation timed out
fatal: Could not read from remote repository.

The aws/s3 dep is not maintained anymore, see mitchellh/goamz#255

We should use this instead

https://aws.amazon.com/blogs/aws/now-available-version-1-0-of-the-aws-sdk-for-go/

In the China (Beijing), EU (Frankfurt) and Asia Pacific (Seoul) regions, Amazon S3 supports only Signature Version 4, and AWS SDKs use this signature version to authenticate requests.

As the new regions only support amazons Signature Version 4 auth it would be awesome to see support for this auth version for semver.

http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingAWSSDK.html

I am trying to use this resource with an S3 bucket and needed to add the required permissions to my AWS user. I got it to work by using the list of permissions mentioned on https://github.com/concourse/s3-resource:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SemverReadWrite",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:PutObjectAcl"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKET_NAME/*",
                "arn:aws:s3:::BUCKET_NAME"
            ]
        }
    ]
}

Perhaps this information should be included in the README?

Hi and thank you for this project!
According to SemVer 2.0 we can define build ID:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

How I can do it with semver-resource?

Our users are heavily using semver resource to manage versions.

Recently some users raised requirement to me. They want to generate version like 1.0.0-SNAPSHOT, but semver seems to not support that. If we use pre, generated version will be 1.0.0-SNAPSHOT.1, and additional pre-version is appended.

After digging deeper, we found that the underlying blang/semver also support a Build field, but the problem is that Build is appended with a + sign, like 1.0.0+Build, and the semver standard requires "+" before Build. So we don't want to break the standard.

But the standard doesn't require "pre" to have extra version appended. Thus we are thinking a solution to add a parameter "no-pre-version" to source of semver resource. If this flag is turned on, then just append pre to version without attaching an extra version.

If this solution is ok, we can raise a PR. @vito

Had a situation, where the user that was pushing to our git repo didn't have push rights to a restricted branch. As a result, the step was running over and over again. There was no helpful information as to what was happening.

I think it would be nice if errors from git were surfaced to the logs and retry had a limit.

It appears resource-semver, unlike resource-s3, is unable to write to S3 buckets which have a policy requiring encryption. This is a problem for companies that require all S3 assets use encryption (such as one of my clients).

Here is an example policy that might be applied to the S3 bucket:

{
    "Id": "PutObjPolicy",
    "Statement": [
        {
            "Action": "s3:PutObject",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "AES256"
                }
            },
            "Effect": "Deny",
            "Principal": "*",
            "Resource": "arn:aws:s3:::NAME-OF-YOUR-BUCKET/*",
            "Sid": "DenyIncorrectEncryptionHeader"
        },
        {
            "Action": "s3:PutObject",
            "Condition": {
                "Null": {
                    "s3:x-amz-server-side-encryption": "true"
                }
            },
            "Effect": "Deny",
            "Principal": "*",
            "Resource": "arn:aws:s3:::NAME-OF-YOUR-BUCKET/*",
            "Sid": "DenyUnEncryptedObjectUploads"
        }
    ],
    "Version": "2012-10-17"
}

resource-s3 is able to write to a bucket with the above policy, it would be great if resource-semver could too.