Environment-specific outdated_mode?

[jsw800]

Details

On my team, we would like to enforce that our dev environment is always up to date with main, but other environments such as staging and production don't have that requirement, as sometimes we need to branch deploy a hotfix branch there which will most definitely be out of date with main, so the outdated enforcement becomes a hindrance.

For a while we had just disabled outdated checks for all environments, but it's caused the occasional confusion when people accidentally deploy outdated changes to dev where that's unexpected 😅 so we're looking to go back to properly enforcing those rules.

Since the environment/command parsing all happens internal to the branch deploy workflow, I can't figure out a way to make the outdated_mode environment specific. For the time being I've implemented a bit of a workaround where I have my own step after the branch deploy step that checks the environment and is_outdated outputs and responds accordingly, but it's a bit hacky, and has the side-effect of showing the "deployment triggered" comment before then displaying my own custom outdated comment, which certainly isn't ideal 😅

I'm wondering if this is something that would be feasible for the workflow to support internally?

[GrantBirki]

@jsw800 I think that sounds like a great idea and I totally understand your use case.

How would something like this sound:

If the outdated_mode input is set to a single option such as strict then that option is applied to all environments. If the outdated_mode input is set to an comma separated list of options:environments, use that option for the given environment. For example: outdated_mode: production:pr_base,dev:strict,staging:pr_base.

Now of course, if you had these new mappings for outdated_mode we would also need them for the update_branch input option as well to control how we handle "out of date" branches.

Full example:

- name: branch-deploy
  id: branch-deploy
  uses: github/[email protected]
  with:
    trigger: ".deploy"
    outdated_mode: production:pr_base,dev:strict,staging:pr_base # this here shows "dev" is the most strict for determining "out of date" branch logic
    update_branch: production:disabled,dev:warn,staging:disabled # this here shows that staging & production will let you deploy "out of date" branches, but the dev env will reject those deployment and warn you that your branch is "out of date"

Additionally, I think it would make sense to fall back to the default input option if a user simply leaves out a mapping for how an environment should be handled. For example, strict is the default for outdated_mode. If a new env gets used called sandbox, and it doesn't have a mapping, then it should fall back to strict rather than failing the Action due to a missing definition.

[jsw800]

@GrantBirki That'd be awesome!