7

I would direct you to my post Coupling docker registry and source control where dmaze answered from the official forums.docker.com. Commit hash and branch name or tags suffices. In your Dockerfile, use a LABEL to record the source of the build. That probably includes the commit hash from distributed source control (git, Mercurial), the branch name if ...


3

IMO these could be possible synonyms for scripted, in the context of your question here: in a textual format, which you can edit in some editor, like YAML, XML, JSON, PHP, etc. NOT in a binary format, the result of some build process (like a .EXE file, etc). And I bet the reason for the "key prerequisite" (as in your quopted text), is that in the end you ...


3

It seems to me that your customers should be dictating the versioning. Both teams seem to be heading towards the same thing but only partially understanding the customer impact. For development, when they significantly re-architect components, there is risk because this could corrupt data or leave core features in a malfunctioning state - this should be ...


2

How to ensure that each tag has a unique semantic version number for the specific images? One could create a tag that consists of multiple elements, e.g. a combination of a timestamp, git commit hash and semantic version. The latter has to be set manually, while the first two could be automated. Such a tag could look as follows: 20171015141729-...


2

Version bumps should happen every single build. Waiting until a formal release and releasing everything as 1.0.0 is an option, but you should still know what build you are using in your alpha/beta. Ultimately, the developer will have to determine if a major release increment is needed. You should only do a major release bump if you introduced a breaking ...


1

Simplest answer is to just revert the commit. AWS Code Commit is standard Git and will support everything Git allows you to do. I.e. find commit hash: git log -n1 commit 444c954e458cc446e2a7a1f2659adf71bdf55580 (HEAD -> my-branch, origin/my-branch) Then do the revert: git revert 444c954e458cc446e2a7a1f2659adf71bdf55580 git push It'll revert your repo ...


1

This is not the default behavior of git so you have made some local config change to cause this to happen. Look in your ~/.gitconfig to see if there's anything that doesn't make sense to you. Try commenting it out. The core.pager setting is one of the first things I would check. This stackoverflow question has a variety of options for dealing with this ...


1

I suggest to follow the principles that are defined in the Semantic Versioning 2.0.0 documentation.


1

The best way is of course (like Zeitounator comments) to use a inventory var. Either you use the version number in the docker-compose task as a variable or you create a Jinja2 template docker-compose.yml.j2 and use the variable there. That's what I do. Example: all: hosts: host1.prod: image: "xyz/12" host2.dev: image: "xyz/latest" ...


1

The two approaches whilst somewhat overlapping solve two different problems: Feature flags allow you to decouple the action of deployment from the action of release. i.e. you can push a change to an API that adds functionality to support a new feature, then when your product owner wants to release it all they need to do is toggle the feature on. API ...


1

I just needed to set publish = true I then enconter another issue for creating seprat versions but finding this answers my initial question


1

Your string isn't being interpolated at the correct time because it's in single quotes. Instead it's being passed to the checkout method as an un-interpolated string. By the time the checkout method interpolates the string, the perf variable is out of scope and so interpretation of this variable falls back to a blank string. Something like this is what ...


1

we now want to release faster And from your comment: Basically, since the artifacts depend on each other, we need to release them in the correct sequence. And since there's a lot of them, it takes some time. I think you're having an X/Y problem. Yes, versioning plays a role, but it seems like you would benefit from solving the source of your problem ...


1

In my opinion the software version should not be updated if the documentation changes, while the software itself does not change. I do not prefer to use different versioning for technical documentation and software as the docs are related to a certain software version. Different versioning will result in confusion. In conclusion, one could use the same ...


1

I suppose that you use one of the DevOps tools for CI/CD like Jenkins, I suggest the following approach, If you use something like Jenkins- You can configure your job such a way that you can use Jenkins environment variable "BUILD_ID", which retrieves the build id of the job when triggered to tag it to your image. This way you can version control your ...


Only top voted, non community-wiki answers of a minimum length are eligible