I have multiple projects that have the same setup:
A few lines defining 4 different environment (with their variables) and many many many lines of identical jobs and workflows.
I would like to create an orb that would include all the jobs and workflows but not the environment variables.
Then, in my projects, I would define the environments in each project and call the orbs.
Like that, whenever I want to modify the setup, I would only have to modify the orbs.
Is there any way to pass variables from the projects config.yml to the environments declarations of the orb?
Bonus question: Is there a way to call the orbs without the exact version number?
For Env vars there are a couple different techniques you could employ. The main patterns we tend to use are to either assume the name of env vars and document those as dependencies of running the orb or, in most cases preferably, you create parameters that take environment variable names and set default values there. The user of the orb can then either make the defaults available in their project (or in a context) or override them in their config. We just released (and have not yet documented as of Nov 18) a new parameter type env_var_name that validates the value as a POSIX “name”, so you could use that or a simple string type and then in your steps or environment clauses you can reference those as parameter values – what’s happening in that case is the literal string is being passed through to the runtime environment where it gets resolved. Does that make sense?
To your other question, yes, you can call a fuzzy version number in one of two ways. Either use volatile as the version to mean whatever the highest semver release is, or you can use partial semver as in myns/myorb@1.2 will resolve whatever patch is highest on the 1.2.x semver branch. The same works for the major version to do myns/myorb@1 to mean the newest minor release on 1.x.y. For more details see https://circleci.com/docs/2.0/creating-orbs/#semantic-versioning-in-orbs